Support a user preference for preferring the `type` keyword in auto-imports

[schontz]

Suggestion

Add support in the TS server to include import type and inline type imports when auto-importing.

// TS server auto-imports like so:
import { Foo } from './foo';

// But I want to be able to specify that it should treat types like so:
import type { Foo } from './foo';
// or
import { type Foo } from './foo';

🔍 Search Terms

• inline type import
• import type isolatedmodules

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

See above

📃 Motivating Example

Many build systems require isolated modules (e.g., esbuild), and often require that types be thusly marked when imported. According to my understanding, that is only done manually, as enabling isolatedModules doesn't seem to affect things.

💻 Use Cases

Work better with isolated module build system requirements. One could also argue that legibility is improved with type imports.

[schontz]

If there is some way to accomplish this in current versions, fantastic, but I cannot find anything in the docs.

[fatcerberus]

verbatimModuleSyntax might do what you want.

[DanielRosenwasser]

That's correct, I believe we chose not to have specific user options here, in favor of performing this based on verbatimModuleSyntax.

[guillaumebrunerie]

Why not always do it? Are there some drawbacks to this syntax?

[schontz]

The docs indicate there are some other side-effects of using verbatimModuleSyntax.

How can you get type imports without other side effects?

[benasher44]

For folks needing isolatedModules: true and moduleResolution: "NodeNext", it feels like TypeScript is auto-adding incorrect imports (i.e. auto-adds imports that won't compile unless they're a type imports, in this mode), so an eslint rule is needed to correct them. It would be great to at least do this by default when the TypeScript compiler requires it. There is some nuance too that eslint is missing today, where it doesn't correctly respect this combination with emitDecoratorMetadata: true.

[benasher44]

Actually now that I've written this, I would push for this to not be a user preference (or at least be fixed in this mode, in addition to being a preference in other cases) and instead be "fixed". If you're using this specific combination of flags, you're going to always be fighting TS's auto-imports, when you go to do a full build.

[DanielRosenwasser]

@benasher44 it's unclear what you're referring to - can you file a separate issue if you think there's a bug?

[DanielRosenwasser]

The docs indicate there are some other side-effects of using verbatimModuleSyntax.

How can you get type imports without other side effects?

I think there's a misunderstanding. The docs are pointing out to the fact that verbatimModuleSyntax will preserve side-effects of any module that you import if it's not a type import. We don't inject any side-effects, we are simply preserving the behavior of your code.

This is in contrast to the original behavior - where if you imported something and never used it as a JavaScript value, then TypeScript would silently drop the import.