Support Node Package Subpath Pattern Imports

[FossPrime]

Bug Report

Typescript ignores Package Subpath Imports breaking the linter when using a loader. These "aliases" are not optional when you have multiple entry points or executables at different levels.

Related to #33079
Making a new bug as the conversation there is about exports... but the import side is also important and has a seperate set of solutions.

🔎 Search Terms

Module alias, import patterns, pwd, es modules, node

🕗 Version & Regression Information

Please keep and fill in the line that best applies:

• This is the behavior in every version I tried

⏯ Playground Link

Running node 16 with ts-node loader in a native ES Module package.

Coming soon from runkit. Integration issues like this are tricky. But I've got the tools to make it so.

💻 Code

// /package.json
  "imports": {
    "#src/*": "./src/*"
  },

import getMongoClient from '#src/models/mongodb.js'

🙁 Actual behavior

"Cannot find module '#src/models/mongodb.js' or its corresponding type declarations.ts(2307)"

🙂 Expected behavior

Should work like regular javascript.

[why520crazy]

I would love to support this feature!

[walkerkay]

I would love to support this feature!

[Cobertos]

As a workaround, you can use the tsconfig.json paths property for now.

An example below an alias I use for the root of my project, #@

// package.json
"imports": {
  "#@/*": "./*"
},

// tsconfig.json
{
  "compilerOptions": {
    // ...
    "paths": {
      "#@/*": ["./*"]
    }
  }
}

[e1himself]

Thanks for the tip @Cobertos

However, this solution is only suitable for application development, when you don't need to export .d.ts files to an external consumer. As when using this for a library build, the generated .d.ts files will have these paths unprocessed. Consuming TS code will fail to compile.

See #26722

[jakub-g]

Relevant link to nodejs "subpath imports" docs:

https://nodejs.org/docs/latest-v16.x/api/packages.html#subpath-exports

[jakub-g]

If I'm reading things correctly, this actually shipped in TS 4.5 beta (link) as part of "ECMAScript Module Support in Node.js" but finally didn't make it into TS 4.5 stable (link)

The biggest change we’ve made since the beta is that ECMAScript module support for Node.js 12 has been deferred to a future release, and is now only available as an experimental flag in nightly releases.

Also, not yet in TS 4.6.

[joshuat]

@jakub-g Correct - here are related issues with more context:

• Concerns with TypeScript 4.5's Node 12+ ESM Support #46452
• Support for NodeJS 12.7+ package exports #33079

[k3n]

However, this solution is only suitable for application development, when you don't need to export .d.ts files to an external consumer.

It would appear that such behavior is expected:

In addition to the "exports" field, it is possible to define internal package import maps that only apply to import specifiers from within the package itself.

Perhaps the problem applies to subpath pattern exports, but that's not what is demonstrated in the details of this issue.

[thetutlage]

Another issue faced is the path during development and post build are not compatible. Given the following subpath imports.

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

If I compile my build with the outDir = build, the subpath should be looking into the build directory now and not the root of the project.

Not sure, if TypeScript can fix this behavior, but it is going to be a common theme, where the subpath imports need to look inside a separate directory post build.