Port TypeScript PR #62844: Gate #/ subpath imports on NodeNext and Bundler

[Copilot]

Port microsoft/TypeScript PR #62844 - Gate #/ subpath imports on NodeNext and Bundler module resolution modes

This PR aligns with Node.js PR nodejs/node#60864, which allows defining symmetric exports and imports fields in package.json:

{
  "exports": { "./*": "./src/*" },
  "imports": { "#/*": "./src/*" }
}

Changes

• Added NodeResolutionFeaturesImportsPatternRoot flag (bit 6) to gate #/ root wildcard imports
• Updated NodeNextDefault and BundlerDefault to include the new flag, while Node16Default excludes it
• Modified loadModuleFromImports() to check feature flag before rejecting #/ patterns
• Added compiler test cases from the original TypeScript PR to verify the behavior

Test Coverage

Added two test cases:

1. nodeModulesPackageImportsRootWildcard.ts - Tests that #/ imports work in NodeNext mode
2. nodeModulesPackageImportsRootWildcardNode16.ts - Tests that #/ imports are rejected in Node16 mode

Behavior

Mode	#/ imports
Node16	Rejected (backward compatible)
NodeNext	Allowed
Bundler	Allowed

Imports like #cjs or #utils (not starting with #/) continue to work in all modes.

Original prompt

Port microsoft/TypeScript#62844

Custom agent used: Strada to Corsa Port Expert
A Go and TypeScript expert who can easily figure out how to port PRs from one language to another

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Copilot]

Pull request overview

This PR ports TypeScript PR #62844, which enables #/ root wildcard imports in package.json imports fields for NodeNext and Bundler module resolution modes. This aligns with Node.js PR nodejs/node#60864, allowing symmetric patterns between exports and imports fields.

Key changes:

• Adds a new NodeResolutionFeaturesImportsPatternRoot feature flag to control #/ root wildcard support
• Updates NodeNextDefault and BundlerDefault to include the new flag, while Node16Default excludes it for backward compatibility
• Modifies the import resolution logic to conditionally allow #/ patterns based on the feature flag

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
internal/module/types.go	Defines the new NodeResolutionFeaturesImportsPatternRoot flag and includes it in the appropriate mode defaults (NodeNext, Bundler, All) while excluding it from Node16 for backward compatibility
internal/module/resolver.go	Updates loadModuleFromImports() to conditionally reject #/ imports only when the feature flag is not set, allowing the pattern in NodeNext and Bundler modes

[Copilot]

This change enables #/ root wildcard imports for NodeNext and Bundler modes but lacks test coverage. According to the project guidelines, at least one minimal test case should be added to verify the new behavior works correctly in each mode (Node16 rejects, NodeNext/Bundler accepts). Consider adding a test in testdata/tests/cases/compiler/ that demonstrates:

1. #/ pattern being rejected in Node16 mode
2. #/ pattern being accepted in NodeNext mode
3. #/ pattern being accepted in Bundler mode

The test should include a package.json with an imports field like "#/*": "./src/*" to match the example from the PR description.

[jakebailey]

Sad there's no test but it's correct, so

[RyanCavanaugh]

@copilot also copy the compiler testcases from the original PR. Do not port the fourslash test

[Copilot]

@copilot also copy the compiler testcases from the original PR. Do not port the fourslash test

Added the compiler test cases from the original PR in commit 400b4d7. The tests verify that:

• #/ patterns work correctly in NodeNext mode (resolves to the mapped path)
• #/ patterns are rejected in Node16 mode with error TS2307

Did not port the fourslash test as requested.

[jakebailey]

A bit sad I didn't notice that the original PR didn't just use one test with node16,nodenext,bundler, but, oh well

[magic-akari]

A bit sad I didn't notice that the original PR didn't just use one test with node16,nodenext,bundler, but, oh well

Thanks for the feedback! I intentionally separated the error cases into a distinct test file because I thought it would make the error baselines cleaner and easier to read. But now I'm wondering if that separation was actually necessary. For future reference, would it be better to combine them into a single test with node16,nodenext,bundler? I'd appreciate any guidance!

[jakebailey]

Yeah, it makes separate baselines, so is a pretty good solution to this.