Skip to content

Conversation

@andrewbranch
Copy link
Member

Noticed this while reviewing @johnnyreilly’s post about importsNotUsedAsValues, verbatimModuleSyntax, and eslint.

importsNotUsedAsValues would produce errors any time the whole import declaration wasn’t marked as type-only but could be, so the error span was over the whole import, and the only fix that would satisfy it was to use a top-level import type. verbatimModuleSyntax, on the other hand, cares more about whether the individual import specifiers are safe to emit, so the error span from that option is placed on individual import specifiers, and using a type modifier on each specifier can satisfy the check. However, under verbatimModuleSyntax, it’s generally preferable to use a top-level import type on the whole import declaration when possible, and the built-in codefix hadn’t been updated to consider that. Even though it’s no longer a TS error to have an import that will unnecessarily be emitted to JS, default behavior from auto-imports and codefixes should avoid that.

For individual fixes, both fix options are offered if import type is possible, with the import type being sorted first:

image

Using import type is not possible when other specifiers are already used as values:

image

For fix-all, import type is used whenever possible.

@typescript-bot typescript-bot added Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels May 15, 2023
@andrewbranch andrewbranch changed the title Code fix should prefer top-level type-only imports Code fix should prefer import type May 15, 2023

if (some(importDeclarationChanges)) {
return [
createCodeFixActionWithoutFixAll(fixId, importDeclarationChanges, Diagnostics.Use_import_type),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m not sure if the two fix options should have different fixNames

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change looks good to me but i don't know about this either.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Asked at the editor sync and this is only used for telemetry, and the telemetry stakeholders don’t care if they have the same name.

Copy link
Member

@jakebailey jakebailey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, though it seems like our Convert ... language is somewhat universal; is it worth preserving that wording?

@andrewbranch
Copy link
Member Author

I think it’s usually better to quote exact syntax, and “type-only import” is ambiguous between type-only import declarations and type-only import specifiers. Not sure how to preserve the word “convert” and disambiguate, and I also don’t think I like the word to describe just adding a modifier.

@andrewbranch
Copy link
Member Author

I’m going to add a fix-all test before merging.

@andrewbranch andrewbranch merged commit 1e0b2f4 into main Jun 1, 2023
@andrewbranch andrewbranch deleted the convert-type-only-import-improvements branch June 1, 2023 16:57
@microsoft microsoft locked as resolved and limited conversation to collaborators Oct 22, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

5 participants