🔍 Search Terms

import type auto-import

✅ Viability Checklist

• 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 our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

When an import is generated automatically (by the language server?), I'd like to be able to have it generate a type import if the imported symbol is used in the file only as a type. Probably, this preference would have options for whether the type import should be of the import type or the import { type ... } form.

📃 Motivating Example

See below

💻 Use Cases

Some codebases prefer to use type-only imports whenever possible to indicate to readers that an import isn't actually used as a value. Meanwhile, other codebases prefer the brevity of import without type.

Currently, a number of TS compiler settings influence the auto-imports that the language server generates, but some of those settings are hard to turn on in existing codebases (e.g., verbatimModuleSyntax, because of how it effects interop) and others are deprecated. Moreover, none of them are actually designed to apply a stylistic preference across the board — they only lead to type imports being generated when it's absolutely necessary for interop, so they won't generate type-only imports as often as a user of this preference would want.

@andrewbranch made the case for adding preference in #54664

The flags that affect type-only auto imports... affect things in precisely the way that the compiler requires, minus bugs. None of them are specifically designed to control auto-imports. It sounds like an antipattern to use compiler options that are supposed to control real things in order to arrive at an editor behavior that matches a particular stylistic preference, so I would much rather give you a user preference.

Really, this issue is just a duplicate of #54664, because the original author closed that issue for unrelated reasons.