Offer auto-import of hand-authored .d.ts files using .d.ts extension

[michaelhays]

I'm working on a TypeScript project with this relevant config:

package.json

{
  "type": "module"
}

tsconfig.json

{
  "compilerOptions": {
    "allowImportingTsExtensions": true,
    "module": "nodenext",
    "moduleResolution": "nodenext"
  }
}

I'd like VS Code to automatically import .d.ts files with their true extension, but they're currently being imported with the .js extension.

Auto import:

import ImportTest from "./importTest.js";

const test: ImportTest = "test";

Desired import:

import type ImportTest from "./importTest.d.ts";

const test: ImportTest = "test";

VS Code auto imports with the .js extension both when bringing up the help popover with ctrl+space, and when saving with addMissingImports enabled on save.

I've tested this with the built-in TypeScript 5.0.2 on the March 2023 release of VS Code.

Here's a video demo:

vscode-import.mp4

[fatcerberus]

Since this is about hand-authored .d.ts presumably without corresponding .js files, this thread feels relevant:

• Module documentation tracking issue #52593 (comment)
• Module documentation tracking issue #52593 (comment)

In particular (emphasis mine):

So the potential harm is readily apparent: if you hand-author only-types.d.ts and then write import {} from "./only-types.js", this resolves and is legal in all settings, but in verbatimModuleSyntax, the import will be preserved and crash at runtime. While TypeScript has type-only imports and exports, it lacks the analogous concept of a type-only module, one which exists for type information purposes but is known to not exist at runtime, though I’ve casually suggested multiple times that such a concept could be useful.

In other words, this pattern is already something of a footgun and I'm not convinced TS should actively encourage pulling the trigger by acknowledging the existence of the standalone d.ts file.

[RyanCavanaugh]

Yeah, it's subtle but you should really not ever write a .d.ts file for a module with no corresponding runtime module. That said, people are going to do it no matter how much we tell them not to.

Thinking about this more... we're not ever going to automatically offer up imports which are actively bad ideas.

[michaelhays]

Thanks for the explanation! Kind of a bummer, as I like the signal of intent that a .d.ts offers as a type-only file, but the rationale makes sense.

[fatcerberus]

I like the signal of intent that a .d.ts offers as a type-only file

Yeah, as discussed in the thread I linked above, .d.ts isn't really a "type-only module" file type (no such concept exists in TS today), but instead it's a "this is the shape of the accompanying JS module" file type (which is why TS produces empty .js files for .ts files containing only types). If there isn't actually an accompanying JS module, it might still work, but you're more or less in unsupported territory.