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

[Sean Callahan (Scalahansolo)]

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

[Jake Bailey (jakebailey)]

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

Andrew Branch (@andrewbranch)

[Andrew Branch (andrewbranch)]

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

[Sean Callahan (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?

[Andrew Branch (andrewbranch)]

I think gating it is fine for now.

[Andrew Branch (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.

[Sean Callahan (Scalahansolo)]

Excuse my ignorance, but for a PR like this that is marked for TS 6.0, when / what is the process for this landing in TS 7?

[Ryan Cavanaugh (RyanCavanaugh)]

Great question! It needs to be ported now. I started microsoft/typescript-go#2330 and we'll see how that goes

[Akhil.p (akhilsmokie7-cloud)]

npm install -D typescript@beta

[Andrei Danciu (danciudev)]

I can't get VS Code's autocomplete to work with subpath imports. Is it possible that it doesn't support this yet?

[Aman Mahajan (amanmahajan7)]

Sorry if this is obvious — with TypeScript 6.0 supporting package.json#imports (including #/ subpath imports), does this mean we can fully replace tsconfig.paths with imports?

Or does TypeScript still require matching paths in tsconfig.json for type checking?

[Andrew Branch (andrewbranch)]

Subpath imports have been supported for type checking since TypeScript 4.7—since then, if your moduleResolution setting is node16/nodenext/bundler, you've never needed to replicate your Node.js-valid package.json "imports" into tsconfig.json paths. Node.js 20+ and TypeScript 6.0+ just expand the valid syntax a little bit.