Do I need to use the "import type" feature of TypeScript 3.8 if all of my imports are from my own file?
Asked Answered
F

1

142

I have a simple file types.ts that defines some types:

export interface MyInterface {
   // ...
}

export const enum MyEnum {
   // ...
}

export type MyType = {
  // ...
}

I have read about the new feature import type for the latest typescript here. As far as I understand, it is meant to fix specific problems which seem mostly to happen when importing from .js files.

I can import my types with both import and import type statements. Both seem to work equally fine. The question is should I prefer import type because it is more explicit and helps me to avoid some theoretical edge-case problems or can I just use import for simplicity and rely on import elision to remove these from compiled code?

In other words: are there any benefits of using import type here or should it rather be used for specific cases to work around import elision shortcomings?

Fredericafrederich answered 24/4, 2020 at 15:33 Comment(1)
similar typescript syntax import { type SomeType, someFunction, SomeClass } is for importing type less verbosely. typescript 4.5 has type modifiers on import names. docAquila
C
174

Short answer: Being more explicit by using import type and export type statements seems to yield explicable benefits by safeguarding against edge-case problems, as well as giving current and upcoming tooling better ground for improving processing performance and reliability with type definition analysis.

Long answer:

As TypeScript 3.8 release notes say:

import type only imports declarations to be used for type annotations and declarations. It always gets fully erased, so there’s no remnant of it at runtime. Similarly, export type only provides an export that can be used for type contexts, and is also erased from TypeScript’s output.

Here are two practical examples of how these remnant imports can cause errors in build or runtime:

Another benefit relates to tooling that is analyzing type definitions. Currently there are details about benefits with bundler setups using Babel, but this may currently or later benefit other tooling as well (like IDE performance).

For Babel users manually configuring their setup: If you are using Babel 7.9=> in your bundler setup with TS 3.8=>, then you can possibly remove the previously needed @babel/plugin-transform-typescript plugin.

For those setups that are using pre-built Babel presets: Babel's team is recommending configuring Babel presets so that explicit type-only imports are being used.

Read more in the blog post: Babel 7.9 Reduces Bundle Sizes, Adds TypeScript 3.8 Support.

More relevant info about Using Babel with TypeScript can be found in the TS docs.

A detailed look into the benefits of using and how to use isolatedModules TS compiler option works can be found in type-only imports — A new TypeScript feature that benefits Babel users

Chartism answered 7/10, 2020 at 11:47 Comment(3)
> If you are using Babel 7.9=> in your bundler setup with TS 3.8=>, then you can possibly remove the previously needed @babel/plugin-transform-typescript plugin. ---- Excuse me, is there a context for this?Cynthea
But isn't TypeScript supposed to not exist at runtime? In my understanding, even import is fully erased at runtime.Farmhand
@Chen Ni - TypeScript in the form of what you wrote doesn't "exist" at runtime but it doesn't just completely disappear. It is transpiled into JavaScript so what you write in TypeScript has a direct effect on what JavaScript is output. Depending on your JS target your import statements may not even change that much from the TS version.Bevin

© 2022 - 2024 — McMap. All rights reserved.