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.

Edit: I've created a repro repo.

[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

[valler]

I have created a minimal repro repo. As mentioned you can't reproduce it on the playground, because it requires multiple files.

Link to repro repo

[RyanCavanaugh]

Specifiers aren't paths

Yes, this is the entire point of the error. rewriteRelativeImportExtensions is only for syntactic rewriting of paths; this was an explicit invariant we set down when writing the feature, because when you can only see the input file itself, you don't know whether the export map said

  "imports": {
    "#root/*": "./*"
  },

(should rewrite)

or

  "imports": {
    "#root/file.ts": "./file.js"
  },

(should not rewrite)

[valler]

Yes that's also how I understand the error message and how I understand rewriteRelativeImportExtensions.
The point is, it's fine (by now, or depending on your use case) to refer to TS files directly.

I see the problem you're illustrating, but simply put, that's not how those package.json / Node.js features work 🤷

What this does right now is, that one can happily use any string to remap, except for the .ts extension, which in turn kills simple postfix wildcards (trailing star) all together and blows up the number of entries from "one" to "as many extensions as you have" for every entry which contains TS files which are actually imported.

[Edit: Deleted a paragraph. Made no sense]

In general if you "only see the input file itself" then what you see is a specifier and therefore can't treat it like a path, [Edit: strike the following, rewriting is not applicable to specifiers:] which in turn means you always have to look up what this thing is pointing at, if your goal is to figure out if to rewrite or not.

Edit: To be clear on the syntactic part - A syntactic extension applies only to paths. Specifiers have no "extensions", because of remapping, they are arbitrary opaque strings except for the semantic prefixes (e.g. hash #) and should never be rewritten. Hence, renaming of the title to

Support detecting whether resolved targets are files, or not, under rewriteRelativeImportExtensions

is not at all what this issue is about. Quite the opposite: Don't touch specifiers. As the feature flag suggests, it should only apply to relative imports. This then leads to the question: Why not paths in general?

Edit, more info, this is Node.js and the feature is called rewriteRelativeImportExtensions, so where does or should it apply:

• /absolute
• ./relative
• bare
• @bare/scoped
• #bare/internal
• file://
• data:
• node:

If you named your package @scope/foo.ts, what would happen? Would TS rename my main entry point? Respectively will it error because it says it (correctly) won't rewrite? Edit: It doesn't rewrite and it doesn't error in this case.

From the 5.7 release notes linked to from the docs (emphasis theirs):

To support this scenario, we’ve added a new compiler option called --rewriteRelativeImportExtensions. When an import path is relative (starts with ./ or ../), ends in a TypeScript extension (.ts, .tsx, .mts, .cts), and is a non-declaration file, the compiler will rewrite the path to the corresponding JavaScript extension (.js, .jsx, .mjs, .cjs).

So it should apply to none but one in the previous list, given it satisfies the latter constraints as well.

This issue is not a suggestion, it's about a bug.

[valler]

Alright, the error goes away with a stripped down config. The first works, the second breaks. Now it's just a matter of bisecting this. I'll post an update when I've found the flag that causes the error to occur.

The first works:

{
  "compilerOptions": {
    "module": "nodenext",
    "moduleResolution": "nodenext",
    "resolvePackageJsonExports": true,
    "rewriteRelativeImportExtensions": true,
    "target": "esnext",
  }
}

The second breaks:

{
  "compilerOptions": {
    "strict": true,

    // type checking    
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "exactOptionalPropertyTypes": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitAny": true,
    "noImplicitOverride": true,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "noPropertyAccessFromIndexSignature": true,
    "noUncheckedIndexedAccess": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "useUnknownInCatchVariables": true,

    // modules
    "allowArbitraryExtensions": true,
    "allowImportingTsExtensions": true,
    "module": "nodenext",
    "moduleResolution": "nodenext",
    "noUncheckedSideEffectImports": true,
    "resolveJsonModule": true,
    "resolvePackageJsonExports": true,
    "resolvePackageJsonImports": true,
    "rewriteRelativeImportExtensions": true,
    "types": [],

    // emit
    "noEmitOnError": true,

    // js support
    "allowJs": false,
    "checkJs": false,

    // interop constraints
    "erasableSyntaxOnly": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "isolatedModules": true,
    "verbatimModuleSyntax": true,

    // language and environment
    "lib": [
      "esnext"
    ],
    "target": "esnext",

    // output formatting
    "noErrorTruncation": true,
    "pretty": true,

    // completeness
    "skipLibCheck": true,
  },
  "exclude": [
    "**/node_modules/**"
  ]
}

[valler]

False positive. Toggling noUncheckedSideEffectImports masked the error because I was testing on a side effect import. The bug remains always present for imports that are actually checked.

Edit: This made me recheck the main entry point example from before, maybe that was masked because of a laxed config as well. But no:

import "@scope/foo.ts" // main entry point works (good)
import "@scope/foo.ts/bar.ts" // subpath breaks (bug; bad)