TSC should not error on valid subpath specifier syntax (TS2877)

[valler]

🔎 Search Terms

TS2877

🕗 Version & Regression Information

This changed between versions 5.6 and 5.7 (best guess; 5.7 introduced rewriteRelativeImportExtensions).

⏯ Playground Link

https://www.typescriptlang.org/play/?rewriteRelativeImportExtensions=true&resolvePackageJsonExports=true&resolvePackageJsonImports=true&noUncheckedSideEffectImports=true&allowArbitraryExtensions=true&allowImportingTsExtensions=true#code/PTAEEkFsAcHsCcAuBnUAbAlgawKakQBY7J4DGAhgK4mgAqAygEwAcA7KwDQBQIoA7kQB2oDMIBm5UonxF4OAOSpBsQqIDm-eLEEbyAI1iVphHJAB0XHmAACKALQ4AHtBxSH8LfABcMjKj6GaAAmoHIAjpQYcqDkoNCSWORqOGYAVsja+LChxLBoAG44XBgwCNIARADE5JikKSjlANxcQA

💻 Code

// Imports like these cause TS2877,
// when in fact there's nothing wrong about them.
import "#alice.ts";

🙁 Actual behavior

error TS2877: This import uses a '.ts' extension to resolve to an input TypeScript file, but will not be rewritten during emit because it is not a relative path.

🙂 Expected behavior

Don't error.

Additional information about the issue

Specifiers aren't paths. Especially subpath imports and exports allow for almost arbitrary string rewriting. The compiler is blatantly wrong about this.

[valler]

More on that:

• Clients only care about URLs. The string is more or less an opaque identifier. Whether it causes import map bloat on the client is an orthogonal problem.
• Every server side engine happily consumes TS files. Pointing to TS files and keeping any postfix unaltered is perfectly fine. The following snippet shows where this comes in handy:

{
  "// some package.json": "",
  "// everything will be compiled into a single bundle": "",
  "// internal specifiers don't matter at all for consumers": "",
  "imports": {
    "#source/*": "./source/*"
  }
}

// source/somehwere/deep/in/source/module.ts
import "#source/my-friend.ts";
// instead of
import "../../../../my-friend.ts";

[valler]

Even this should be OK:

{
  "// for whatever reason, I want this to export all source files": "",
  "name": "@scope/package",
  "type": "module",
  "exports": {
    ".": "./source/index.ts",
    "./*": "./source/*"
  }
}

[jakebailey]

If you flip your resolution mode to a node-based one (or bundler), I believe this error goes away. The playground is set to esnext by default.

[valler]

Could it be anything else? I have both module and moduleResolution set to nodenext with resolvePackageJsonExports and resolvePackageJsonImports set to true