[4.5.3][4.6.0-20211212] wrong diagnostic on specifier-specific "type" and importsNotUsedAsValues="error"

[AviVahl]

Bug Report

🔎 Search Terms

importsNotUsedAsValues

🕗 Version

4.5.3, when specifier-specific type keyword was added.

⏯ Playground Link

The playground doesn't allow setting importsNotUsedAsValues

💻 Code

// this works

import type { VFC } from 'react';
export const Hello: VFC<{}> = () => <main>Hello World</main>;

and:

// this reports diagnostics

import { type VFC } from 'react';
export const Hello: VFC<{}> = () => <main>Hello World</main>;

should behave the same (no error)

🙁 Actual behavior

This import is never used as a value and must use 'import type' because 'importsNotUsedAsValues' is set to 'error'.ts(1371) on second piece of code.

🙂 Expected behavior

Both examples should not report diagnostics.

@andrewbranch I feel like this is your cup of tea. :)

[MartinJohns]

I have never seen this syntax. Where did you get it from? All documentation I can find always uses import type, which then counts for all imported types from this statement. I don't think the type is a modifier for individual imports. I would actually expect this to be an error.

[AviVahl]

@MartinJohns it was added in 4.5: https://devblogs.microsoft.com/typescript/announcing-typescript-4-5/#type-on-import-names

[MartinJohns]

Thank you, I definitely missed that one! Then I absolutely agree with your expected behaviour.

[andrewbranch]

I think this is working as intended? When you use --importsNotUsedAsValues error, you are saying “If I write an import declaration, (a) always emit it to JS, and (b) make sure there is an apparent reason why I wrote it in such a way that it needs to be in the JS.” When you write import { type VFC } from "react", you are asking for import {} from "react" to be emitted to the JS. That request doesn’t pass muster with --importsNotUsedAsValues error. It sees an import that is going to be emitted to JS needlessly.

The logic goes like this:

• import type { VFC } from "react" emits nothing (because what could it emit?)
• import { type VFC } from "react" emits import {} from "react"
  • This subsequently gets removed under --importsNotUsedAsValues remove (the default) because it is an import that doesn't bring in anything that gets used in an emitting position. (In actuality, these two steps are just one swoop by the transformer, but I think it makes more sense to think of it as two.)

Does that clear it up?

[andrewbranch]

Another helpful piece of the mental model:

• import type operates at the ImportDeclaration level
• import { type ... } operates at the ImportSpecifier level
• importsNotUsedAsValues operates at the ImportDeclaration level (this is the one that’s easy to mix up)

[Pika-Pool]

...but it would be nice to avoid two import statements for the same module. That’s part of why TypeScript 4.5 allows a type modifier on individual named imports, so that you can mix and match as needed.
-- taken from https://devblogs.microsoft.com/typescript/announcing-typescript-4-5/#type-on-import-names

I still have to write 2 import statements if I have this flag set to error. I think this should be fixed

[AviVahl]

There are several oddities when working with the model you're describing, @andrewbranch
Consider the following code:

import { memo, type VFC, type HTMLAttributes } from 'react';

export const Main: VFC<HTMLAttributes<HTMLElement>> = memo((props) => <main {...props}>Hello World</main>);

If I remove usage and import specifier of memo, I must also remove the type keyword from the other two specifiers and re-add it as prefix of the import declaration.

I guess my (wrong) assumption was:
"If all specifiers of an import declaration are prefixed with type, it's the same as prefixing the entire import declaration with type"

I understand it's the same as to how the specifiers themselves behave in the module, but it's not the same to whether the import declaration is removed or not.

I won't lie, this is not the most intuitive behavior.

[andrewbranch]

"If all specifiers of an import declaration are prefixed with type, it's the same as prefixing the entire import declaration with type"

This is true under --importsNotUsedAsValues remove (the default). It sounds like that’s what you want.

[harunurhan]

@andrewbranch I don't think this was really clear in release notes, it sounded like just a syntatic sugar so we won't need another import statement. I thought if all members are type, then TSC would drop the entire import statement.

We can get this behaviour with --importsNotUsedAsValues remove, but is it possible to get it on TS v5+ using --verbatimModuleSyntax?

Considering the eslint rule people use for enforcing and auto fixing type imports also introduces this option as fixStyle without any documentation that it would change what TSC would emit, I think many people will fall into this trap.