Configuration to auto-import with inline type specifiers

[angrybacon]

🔍 Search Terms

"inline type specifiers", "preferTypeOnlyAutoImports"

✅ 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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Preamble

I did check the "Design Goals" guideline from the checklist but have doubts towards this one item since import { type T } from ... and import type { T } from ... don't necessarily behave the same wrt/ bundlers

9. Use a consistent, fully erasable, structural type system.

For reference, this issue was ported from typescript-language-server/typescript-language-server#1068

This issue is about providing more control over the user preference preferTypeOnlyAutoImports. I suppose instead of a boolean, it could also accept one of the 2 known styles (to my knowledge): top-level and inline. Though the next question becomes: what happens when a user configures inline and another import statement from the same location already exists in the file using the top-level syntax (and vice versa)

✅ Use Case A

Auto-importing FooProps behaves as expected when a symbol is already imported from the same path

import { Foo, type FooProps } from 'foo';

❌ Use Case B

Current behavior auto-importing FooProps when no symbols are imported from the location yet

import type { FooProps } from 'foo';

Expected behavior

import { type FooProps } from 'foo';

📃 Motivating Example

See https://oxc.rs/docs/guide/usage/linter/rules/import/consistent-type-specifier-style.html

💻 Use Cases

1. What do you want to use this for?
   Have consistent import styles across the codebase

2. What shortcomings exist with current approaches?
   Auto-importing uses the wrong style by default when importing from a then unused path which has to be fixed in order to pass the linter

3. What workarounds are you using in the meantime?
   No workaround

[angrybacon]

Possibly related #54664

[danyalahmed1995]

Hello , This seems like a reasonable usability request, especially for projects that enforce inline type specifiers through lint rules.That said, I’m not sure this currently meets the bar for a Ts 7 change in this repo. The current contribution guidance appears to limit changes here to serious regressions, crashes, security issues, or fixes that are portable across 6.0/7.0 without introducing behavioral changes. Since this looks more like a new language service preference / import organization behavior than a TS 7 parity bug or regression, it may need maintainer guidance before anyone spends time on an implementation.

[MartinJohns]

I’m not sure this currently meets the bar for a Ts 7 change in this repo.

That's for pull requests, not issues in general. And that makes sense because the code base will switch from TypeScript to Go, and they want to reduce the amount of changes they need to port over.

[RyanCavanaugh]

🤖 Thank you for your issue! I've done some analysis to help get you started. This response is automatically generated; feel free to 👍 or 👎 this comment according to its usefulness.

Similar Issues

Here are the most similar issues I found

• (75%) microsoft/typescript#55675: Support a user preference for preferring the type keyword in auto-imports
• (73%) microsoft/typescript#54664: Support a user preference for preferring the `type` keyword in auto-imports
• (73%) microsoft/typescript#56090: Add user preference for preferring type-only auto imports
• (73%) microsoft/typescript#35078: Add option to disable TS using inline import types in quick fixes
• (71%) microsoft/typescript#32555: Offer auto import of types via import type syntax
• (68%) microsoft/typescript#36400: Add QuickFix to create type-only import if a type is only used in a type position in the current file
• (68%) microsoft/typescript#19630: TS auto import should support configuring whether a star or a qualified import is used.
• (68%) microsoft/typescript#20292: Use node require for auto imports?
• (68%) microsoft/typescript#46050: Design Meeting Notes, 9/24/2021
• (68%) microsoft/typescript#43777: Option for auto-import to prefer direct exports over re-exports
• (67%) microsoft/typescript#45065: Allow to Override Import Paths For Auto-Import
• (67%) microsoft/typescript#62008: Support `@import` JSDoc tag for auto-imports
• (67%) microsoft/typescript#59460: `organizeImports` does not merge value and type imports
• (67%) microsoft/typescript#36097: TS 3.7 generates inline imports for typing files (.d.ts) although the source contains imports at the top
• (67%) microsoft/typescript#36038: Feedback on 'import type' UX for editors

If your issue is a duplicate of one of these, feel free to close this issue. Otherwise, no action is needed.

[RyanCavanaugh]

import { type FooProps } from 'foo';

This is a surprising (to me) form to prefer, since it implies a runtime import of 0 identifiers. What's the goal of that lint rule?

[angrybacon]

What's the goal of that lint rule?

As highlighted in the Oxlint link I've posted the rule exists to prevent mixed styles

Supposedly users who prefer the inline style should have code diffs that are less noisy too since all imports from a given location are always grouped in a single statement even when that statement originated as a type-only import and then was added a runtime symbol to it. With "consistent" from the rule name itself being the highlight here

[guillaumebrunerie]

Looks like this rule comes from eslint-import (https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/consistent-type-specifier-style.md) and was added in 2022, so before --verbatimModuleSyntax was added.

Interestingly, there is now also a rule forbidding inline style with only types, and explaining why it's a bad idea to use them: https://oxc.rs/docs/guide/usage/linter/rules/typescript/no-import-type-side-effects

[RyanCavanaugh]

Yeah, no-import-type-side-effects is the rule I'd have expect to see. "Consistently" using per-identifier type modifiers hides a material difference in whether a runtime import is desired or not.