Repository navigation
Should I explicitly separate "import" and "import type" statements? #39861
Description
Activity
Ideally one goes for -
import { Type, value } from "some-module";
import type { Type } from "some-module";for solving specific transcompiler issue like Babel js.
How the error is reproduced:
Transcompilers like Babel JS removes the types whilst transpiling,but it may happen sometimes that whilst transpiling it isn't sure whether a specific import is simply a type (that can be removed ) or an actual value(that is to be kept)
For example:
import { Type } from "./types"; const changeType = (val : Type) => { //some logic };is transpiled to
const changeColor = (color) => { window.color = color; };simply by removing the type.
But removing types simply isn't so obvious in this case:
import { Type } from "./types"; export { Type };
Hence, we need to explicity define these type imports asimport type {Type}.
Otherwise,you should use the genericimport {Type}Reacted by Ian Izaguirre, 0xRoy, Nikhil Patel, Nithin Valappil, Arthur Henrique, Kanstantsin Lazouski, Davi Medeiros, Aaron Meese and Mikhail VetyugovReacted by Dmytro ParzhytskyiThe intention is for you not to use
import typeunless you need to. There’s some discussion related to auto-import at #39432, and there’s a thorough description of the motivations for introducing the feature on the original PR: #35200.If you don’t have a specific need for type-only imports, you could consider them a stylistic choice. My personal suggestion for how to consider that stylistic choice is
- Best style: do not use
import type. This style choice eliminates meaningless distinctions and reduces cognitive load, giving you more time and resources to think about things that matter. - Second-best style: enable
"importsNotUsedAsValues": "error"in your tsconfig, then useimport typeonly where the errors force you to. - Worst style: use
import typeas much as possible, separating values and types from the same module into separate import statements. There is simply no reason to do this, and since there are currently no tools that would enforce this style, it would fall on you to analyze and separate your declarations manually, wasting your valuable coding time.
Reacted by Dmytro Parzhytskyi, Andrii Dieiev, Joshua V Sherman, Miguel Guedes, Cris, Hyeon Ku, Dexin, Christian Rodemeyer, María Simó, Pylyp Borysov and 65 moreReacted by Raven, Hooni, Szymon Pajka, Robert Molina, Xendarboh, Richard Antao, Aleksandr Kunin, Luca Iaconelli, Carlo Patti and greenhead- Best style: do not use
Thanks, Andrew Branch (@andrewbranch), great to hear the author's intent first-hand 👍
I'd argue that the second presented option is actually the best one;
import type, I think, is a useful feature, consistently avoiding using it would be kind of silly. That's up to debate though.Reacted by merrick kirby, Peter Benc, Unvoid - Rafael Lima, Nikhil Patel, Luke Nelson, Isabelly Monteiro, Davi Medeiros and JJ Loneman- changed the title
[-][Question] Should I explicitly separate "import" and "import type" statements?[/-][+]Should I explicitly separate "import" and "import type" statements?[/+]on Aug 3, 2020 I apologize tremendously for reopening this very old thread. Now we have 3 ways to import types
Based on the discussion, I think I should then use the 3 way, right?
import { type Type, value } from "some-module";Those each have different meanings and you should use the one corresponding to the behavior you want to have happen.
Reacted by Nato BoramReacted by Andrés Bedoya (SrHart), Christoffer Bjelke and Davi MedeirosThose each have different meanings and you should use the one corresponding to the behavior you want to have happen.
Where can i read more about the different meaning between
import type { AuthState } from "..."andimport { type AuthState } from "..."?Reacted by Andrés Bedoya (SrHart)Christoffer Bjelke (@chribjel) Above all, the
typeinimport type { Thing, OtherThing } from "things"… applies to both
ThingandOtherThing, while inimport { type Thing, OtherThing } from "things"… the
typeonly applies toThing, whileOtherThingis imported as a value (if it is a value).Dmytro Parzhytskyi (@parzhitsky) That is what i assumed, just got confused when Ryan said the three imports had different meaning.
If you only have ONE imported type they have the same "meaning", or at least ends up meaning the same thing.
If you only have ONE imported type they have the same "meaning", or at least ends up meaning the same thing.
Not under
--verbatimModuleSyntax.// index.ts import type { Thing } from "things-1"; import { type Thing } from "things-2";
becomes
// index.js import {} from "things-2";
Reacted by Dmytro Parzhytskyi, Bilal Quadri, Kirill Taletski, Michał Drobniak, Davi Medeiros, 100k and Samuel Jones- locked as resolved and limited conversation to collaborators
on Oct 21, 2025
A.S.: This is an opinion-based question, I cannot ask such on StackOverflow
I've been using the
import typestatement for a while now, and I wonder, what was the intended use-case for it:import, designed to be used in the case when only type information is actually used, i.e. fallback?I always thought of
import typeas "import for types", the first option, so the code always looked like this:import type { Type } from "some-module"; + import { value } from "some-module";… but auto-import in VSCode suggests it is actually the second, fallback-ish:
Now, I understand that both will work correctly, and it is basically a matter of stylistic choice for the team, but the authors' original intention is important for me, and I'm a sole developer in this case