Allow subpath imports that start with #/

[magic-akari]

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

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

Fixes #62841

[Copilot]

Pull request overview

This PR enables TypeScript to support subpath imports starting with #/* in package.json, aligning with Node.js behavior. Previously, TypeScript rejected these patterns, but they are now valid according to Node.js PR nodejs/node#60864.

• Removed restriction that blocked #/* import patterns
• Added comprehensive test coverage for the new functionality

Reviewed changes

Copilot reviewed 21 out of 21 changed files in this pull request and generated no comments.

File	Description
src/compiler/moduleNameResolver.ts	Removed check that prevented #/* subpath imports
tests/cases/conformance/node/nodeModulesPackageImportsRootWildcard.ts	Added test case validating #/* imports across ESM/CJS modules
tests/cases/fourslash/importCompletionsPackageJsonImportsPatternRootWildcard.ts	Added test for import completions with #/* pattern
tests/baselines/reference/nodeModulesPackageImportsRootWildcard(module=).	Generated baseline files for various module configurations

[Scalahansolo]

Does this implementation handle multiple file extensions? I.e. if a project contains both .ts and .tsx files?

[jakebailey]

I had assumed this would require a new module resolution mode.

@andrewbranch

[andrewbranch]

Yeah, technically this shouldn’t go in node16. @magic-akari can you gate this on moduleResolution === ModuleResolutionKind.NodeNext?

[Scalahansolo]

Shouldn't this also work with moduleResolution being bundler?

[magic-akari]

Thanks for the feedback! I'll gate this feature on NodeNext and Bundler modes. For Bundler, since it doesn't need to strictly align with Node.js versions, I think it makes sense to include it as well.

One question: since this feature was just merged into Node.js (nodejs/node#60864), do we need to introduce a new module resolution mode (e.g., Node24) to represent the updated Node.js behavior? Or is gating it behind NodeNext sufficient for now?

[andrewbranch]

I think gating it is fine for now.

[andrewbranch]

Actually, it sounds like it will be backported as far back as v20, so probably we’ll want to snap the versioned module resolution at --moduleResolution node20, since we have --module node20 and selecting that should enable this. But we’ll want to wait for those backports to happen before merging anything versioned.