fix(function): support multiline import type statements in import scanning

[lightstrike]

Fixes regex pattern in importPathPattern so that multiline import type { ... } and export type { ... } statements are correctly matched during bind-mount file scanning. Without this fix, type-only imports split across multiple lines are silently skipped, causing runtime errors in Deno edge functions.

What kind of change does this PR introduce?

Bug fix — corrects the import-path regex to handle multiline type imports.

What is the current behavior?

The importPathPattern regex in pkg/function/deno.go uses .*? in the non-braced import branch. Since . does not match newline characters in Go's regexp package, multiline import type statements like:

import type {
  Database,
  Json,
} from '../types/database.ts'

are not matched. The referenced module is never bind-mounted into the Docker container, producing a runtime error:

worker boot error: Module not found "file:///.../types/MyType.ts"

This occurs whenever a code formatter (e.g., deno fmt, Prettier) breaks a long import type statement across multiple lines.

What is the new behavior?

The regex replaces .*? with [\s\S]*?, which matches any character including newlines. This is consistent with the {[^{}]+} pattern already used for braced imports elsewhere in the same regex.

Before: (?:import|export)\s+(?:{[^{}]+}|.*?)\s*(?:from)?\s*['"](.*?)['"]
After: (?:import|export)\s+(?:{[^{}]+}|[\s\S]*?)\s*(?:from)?\s*['"](.*?)['"]

All existing single-line imports continue to work. Multiline import type and export type statements are now correctly resolved.

Files changed (4):

• pkg/function/deno.go — regex fix (.*? → [\s\S]*?) + explanatory comment
• pkg/function/deno_test.go — new test case: iterates multiline import type statements
• pkg/function/testdata/modules/import_types.ts — test fixture with multiline import/export type patterns
• pkg/function/testdata/types/database.ts — test fixture target module

Additional context

Why {[^{}]+} doesn't cover import type statements

The regex alternation (?:{[^{}]+}|[\s\S]*?) is evaluated after (?:import|export)\s+. For import type { ... }, the type keyword sits between \s+ and the opening brace, so the position after matching the whitespace is t — not {. The {[^{}]+} branch fails immediately and the engine falls through to [\s\S]*?.

This means all import type forms — braced or not, single-line or multiline — are handled by the second branch. The old .*? worked for single-line cases because it could lazily expand across the entire line, but broke on multiline statements because . does not match \n in Go regex. The [\s\S]*? replacement matches any character including newlines, allowing the lazy expansion to cross line boundaries and reach from '...'.

Why [\s\S]*? instead of the (?s) flag?

Go's regexp supports (?s) to make . match newlines, but applying it globally would change every . in the pattern — including the (.*?) capture groups for the import path, which should remain single-line. [\s\S]*? is a targeted fix that only affects the specifier-matching branch.

Not a regression — an original limitation

The importPathPattern regex was introduced in commit 4b0b2b1d (Feb 2025, "support deploying functions without docker") with .*? from the start. Multiline type imports were never supported. The bug surfaces whenever a code formatter breaks a long import type or export type statement across lines — a common occurrence with auto-generated types or projects using default line-width limits.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

📝 Walkthrough

Summary by CodeRabbit

• Bug Fixes

  • Fixed regex pattern to properly handle multiline import type statements in TypeScript files, ensuring imports and exports spanning multiple lines are correctly parsed.

• Tests

  • Added comprehensive test coverage for multiline import type statement parsing, validating handling of various import and export patterns across single and multiple lines.

Walkthrough

The pull request updates import path parsing for Deno modules to handle multiline import type statements. A regex pattern in pkg/function/deno.go was modified to use [\s\S]*? instead of .*? in the second alternative, enabling matching across newline characters. Corresponding test coverage was added with a new subtest in deno_test.go, and two new test data files were created containing TypeScript type definitions and various import/export type statement patterns to validate the regex behavior.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coveralls]

Pull Request Test Coverage Report for Build 22164832869

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 7 unchanged lines in 2 files lost coverage.
• Overall coverage remained the same at 61.773%

---

Files with Coverage Reduction	New Missed Lines	%
internal/storage/rm/rm.go	2	80.61%
internal/utils/git.go	5	57.14%

Totals
Change from base Build 22142437948:	0.0%
Covered Lines:	7705
Relevant Lines:	12473

---

💛 - Coveralls

[RobSchilderr]

Would be great to get some eyes on this one!

[avallete]

Hey, thanks for tracking this down! The [\s\S]*? change works, but I'm a little hesitant to widen the catch-all branch to match across newlines for everything — even with the lazy quantifier it feels like a broader change than what we need here.

The root issue is that import type { ... } doesn't hit the braced branch because type sits between the whitespace and {. What if we handled that more explicitly instead?

(?:import|export)\s+(?:type\s+)?(?:{[^{}]+}|.*?)\s*(?:from)?\s*['"](.*?)['"]

Adding (?:type\s+)? lets import type { Foo, Bar } fall into the {[^{}]+} branch, which already crosses line boundaries fine. That way .*? stays single-line and we're only changing the behavior for actual type imports rather than everything.

Happy to be wrong if there's a case I'm missing though do you have a test that the (?:type\s+)? approach wouldn't cover?