Skip to content

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

Open
lightstrike wants to merge 2 commits intosupabase:developfrom
lightstrikelabs:lightstrikelabs/fix/multi-line-function-type-imports
Open

fix(function): support multiline import type statements in import scanning#4872
lightstrike wants to merge 2 commits intosupabase:developfrom
lightstrikelabs:lightstrikelabs/fix/multi-line-function-type-imports

Conversation

@lightstrike
Copy link

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.

…nning

The regex pattern `.*?` does not match newlines, causing multiline
`import type { X }` statements to be skipped during bind-mount file
scanning. This results in type-only imports not being mounted in
the Docker container, causing runtime errors like:

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

Changed `.*?` to `[\s\S]*?` to match any character including newlines,
consistent with the `{[^{}]+}` pattern used for braced imports.

This fix enables proper handling of Deno 2.x style multiline type imports:

```typescript
import type {
  MyType,
  OtherType,
} from './types.ts'
```

Includes test case to prevent regression.
Cover `import type Foo from '...'` pattern in the multiline import
type test. This form also routes through the `[\s\S]*?` branch and
was previously untested.
@lightstrike lightstrike requested a review from a team as a code owner February 19, 2026 01:28
@coderabbitai
Copy link

coderabbitai bot commented Feb 19, 2026

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
Copy link

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 Coverage Status
Change from base Build 22142437948: 0.0%
Covered Lines: 7705
Relevant Lines: 12473

💛 - Coveralls

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Comments