fix: resolve multi-line imports in local_import_resolver

[stack72]

Summary

• Fix IMPORT_PATTERN regex in local_import_resolver.ts to match across newlines (.*? → [\s\S]*?), resolving AWS extensions fail to load: missing _lib/aws.ts shared dependency #715
• The clover code generator writes multi-line imports (e.g., import {\n createResource,\n deleteResource,\n} from "./_lib/aws.ts"), which the previous single-line regex silently skipped
• This caused shared dependencies like _lib/aws.ts to be excluded from extension packages during swamp extension push, making all @swamp/aws/* extensions fail on pull with Module not found errors

Changes

• src/domain/models/local_import_resolver.ts: Changed IMPORT_PATTERN from /(?:import|export)\s+.*?from\s+["'](\.\.?\/[^"']+)["']/g to /(?:import|export)\s+[\s\S]*?from\s+["'](\.\.?\/[^"']+)["']/g so the regex matches import/export statements that span multiple lines
• src/domain/extensions/extension_import_resolver_test.ts: Added test case "resolveLocalImports resolves multi-line imports" that creates a _lib/aws.ts dependency imported via a multi-line import statement and verifies it is correctly discovered

Test plan

• New multi-line import test passes
• All 8 import resolver tests pass
• Full test suite passes (2979 tests)
• deno check — type checking passes
• deno lint — linting passes
• deno fmt — formatting passes
• deno run compile — binary compiles successfully

Fixes #715

🤖 Generated with Claude Code

[github-actions]

Review: Approved

This is a well-crafted bug fix with appropriate test coverage.

What's Good

• Correct regex fix: Changing .*? to [\s\S]*? properly handles multi-line imports. The non-greedy quantifier ensures minimal matching, preventing over-matching across multiple import statements.
• Test coverage: The new test case validates the exact scenario from the bug report (multi-line imports with named exports from _lib/ directories).
• Code style: Follows project guidelines - named exports, no any types, proper license header.
• DDD alignment: Infrastructure code appropriately placed in domain layer to support model packaging.

Edge Cases Verified

• Multiple imports on same line: Non-greedy *? stops at first valid from\s+["']
• Import names containing "from" (e.g., transformFrom): Handled correctly since pattern requires \s+from\s+
• Nested newlines in import block: [\s\S] matches all characters including newlines

No blocking issues found.

[github-actions]

Adversarial Review

I systematically attempted to break this regex change across all adversarial dimensions. Here are my findings:

Critical / High

None found.

Medium

None found.

Low

1. Pre-existing: Imports in comments/strings (local_import_resolver.ts:32)
   The regex /(?:import|export)\s+[\s\S]*?from\s+["'](\.\.\?/[^"']+)["']/g has no awareness of code context. A commented import like:

   /* import { foo } from "./commented-out.ts"; */

   would still be matched and the file would be resolved.

   This is NOT introduced by this PR - the old regex had the same limitation. It's a theoretical issue unlikely to cause problems in practice since commented imports usually point to files that exist.

2. Pre-existing: Side-effect imports not matched (local_import_resolver.ts:32)
   import "./side-effect.ts"; is not matched because the pattern requires from keyword.

   Not introduced by this PR - pre-existing limitation, and side-effect imports in extension dependencies are uncommon.

Verification Performed

• Regex backtracking: Verified the non-greedy [\s\S]*? doesn't cause catastrophic backtracking. Match complexity is O(n) per position, acceptable for typical source files.
• Multi-import correctness: Traced regex behavior on files with multiple imports (both single and multi-line). The non-greedy quantifier correctly matches each import independently.
• External import handling: Verified that external imports (e.g., from "@std/path") correctly fail to match the path capture group (\.\.\?/[^"']+) and don't interfere with subsequent local imports.
• Boundary directory enforcement: Confirmed normalizedBoundaryDir check at line 70 prevents path traversal regardless of what the regex captures.
• Test coverage: The new test at line 144-167 specifically exercises the multi-line import case with curly braces that was broken.

Verdict

PASS - The change is minimal, targeted, and correct. The regex modification from .*? to [\s\S]*? properly addresses issue #715 without introducing new bugs. All CI checks pass.