For those who didn't understand: Let's say you have a file "A" where you define a "User" type and a file "B" where you're importing that type. Since Typescript is compiled down to JavaScript the import statement is present in the Javascript as well but since types don't exist in JS it's just an empty import as follows: import {} from './A' To prevent this unnecessary import statement in JS use "import type { User } from './A'" and typescript will understand that you're only importing type from file "A"
1 year ago
| 32
The second line could make more sense if it were like this: If you imported both a type and a component from a file: (TS) import { type User, UserComponent } from "./User"; It would be compiled as: (JS) import { UserComponent } from "./User"; (The User type disappears from the compiled file since types don't exist in JS) When type imports (import type { User } from "./User") were introduced a few versions back I immediately loved it as I knew intuitively that the type import would be automatically removed by the compiler. ✌️
1 year ago | 0
There is also a point to using the "type" keyword only in those cases where you are importing something that is , or might be a value, and chat-gpt helped me out to formulate this point: - - - - - Key Argument: Intent and Contextual Clarity - - - - - Explicitly Convey Intent: By using import type only when importing from modules that contain both values and types, you signal to the reader that you are intentionally avoiding the runtime value and only need the type information. This usage clarifies that the imported item could have runtime code, but you're only interested in the type aspect. Avoid Overuse: If import type is used universally for all types, its significance is diluted. It no longer provides the hint that the source module might contain runtime values. This selective use preserves the meaningful distinction between pure type modules and mixed modules. By reserving import type for situations where the source module might contain both types and runtime values, you: Provide Contextual Information: It helps convey the nature of the imported item and clarifies your intent to use it solely as a type. Maintain Code Readability: It avoids the overuse of the import type keyword, keeping import statements concise where the context is already clear. Enhance Developer Understanding: It serves as a hint to other developers that the source module is multifaceted, potentially containing both types and values. This nuanced approach leverages the import type keyword effectively to enhance code clarity and maintain the intended purpose of import statements.
1 year ago | 1
The confusion comes from this behaviour being entirely config-dependent and the keyword was only introduced to deal with specific edge cases. So technically the examples are incorrect since without config fiddling typescript can elide imports according to its arcane rules with no regards for the keyword.
1 year ago (edited) | 12
As a self taught and relatively intermediate TS dev, I've coincidentally been doing things that you recommend and I feel like I'm pretty much on the right path by myself lol I've been doing it the third way, not because I exactly knew what it compiles to but I felt like, adding the type keyword helps you to figure it's a type import and not a module right away.
1 year ago (edited) | 1
Is complied to the same thing in the first two examples, but the descriptions imply they are somehow different.
1 year ago | 1
My opinion is that the convention in general should be the first line. No "type", completely unnecessary - unless in a case where you are importing a value and you only want the type information from that value. It's annoying that Vue made it mandatory to use "type" everywhere because they turned on verbatimModuleSyntax. So they forced everyone to refactor their projects and add the "type" keyword everywhere, and it does nothing. I don't think a javascript library should make such a choice for the developers. It's rather up to typescript if they want to turn into the default convention.
1 year ago (edited) | 2
Idk man, my vscode tell me to use "import type { Type } from "./type"" and I just "thanks"
1 year ago
| 0
Honestly seems like a bug/flaw in design if you ask me. The end result would look the same regardless.
1 year ago | 0
I use the last method all the time, but I'm not sure if it matters. Is there any compilation optimization involved?
1 year ago | 0
Is there an ESLint rule that can nudge towards 3 when all imported elements are just types? IMO doing 2 should be a very intentional thing (if you really want those side effects) so I'd prefer to be safe by default and always discard imports when possible.
1 year ago | 2
So the third line is best practice? How about if I had to import multiple Types and also multiple functions from a package?
1 year ago | 1
What if you're importing a function and a type from the same file?
1 year ago | 0
Might have made more sense if you say that User has side effect code that runs.
1 year ago | 0
But tree shaking should remove those top two imports if nothing else was imported, given that you're using a bundler (like Vite)
1 year ago | 1
Matt Pocock
There's a bit of confusion about import type knocking around.
Here's how it works:
1 year ago | [YT] | 562