consistent-type-imports
Enforce consistent usage of type imports.
Some problems reported by this rule are automatically fixable by the --fix
ESLint command line option.
TypeScript allows specifying a type
keyword on imports to indicate that the export exists only in the type system, not at runtime.
This allows transpilers to drop imports without knowing the types of the dependencies.
See Blog > Consistent Type Exports and Imports: Why and How for more details.
module.exports = {
"rules": {
"@typescript-eslint/consistent-type-imports": "error"
}
};
Options
This rule accepts the following options
type Options = [
{
disallowTypeAnnotations?: boolean;
fixStyle?: 'inline-type-imports' | 'separate-type-imports';
prefer?: 'no-type-imports' | 'type-imports';
},
];
const defaultOptions: Options = [
{
prefer: 'type-imports',
disallowTypeAnnotations: true,
fixStyle: 'separate-type-imports',
},
];
prefer
This option defines the expected import kind for type-only imports. Valid values for prefer
are:
type-imports
will enforce that you always useimport type Foo from '...'
except referenced by metadata of decorators. It is the default.no-type-imports
will enforce that you always useimport Foo from '...'
.
Examples of correct code with {prefer: 'type-imports'}
, and incorrect code with {prefer: 'no-type-imports'}
.
import type { Foo } from 'Foo';
import type Bar from 'Bar';
type T = Foo;
const x: Bar = 1;
Open in PlaygroundExamples of incorrect code with {prefer: 'type-imports'}
, and correct code with {prefer: 'no-type-imports'}
.
import { Foo } from 'Foo';
import Bar from 'Bar';
type T = Foo;
const x: Bar = 1;
Open in PlaygroundfixStyle
This option defines the expected type modifier to be added when an import is detected as used only in the type position. Valid values for fixStyle
are:
separate-type-imports
will add the type keyword after the import keywordimport type { A } from '...'
. It is the default.inline-type-imports
will inline the type keywordimport { type A } from '...'
and is only available in TypeScript 4.5 and onwards. See documentation here.
- ❌ Incorrect
- ✅ With separate-type-imports
- ✅ With inline-type-imports
import { Foo } from 'Foo';
import Bar from 'Bar';
type T = Foo;
const x: Bar = 1;
Open in Playgroundimport type { Foo } from 'Foo';
import type Bar from 'Bar';
type T = Foo;
const x: Bar = 1;
Open in Playgroundimport { type Foo } from 'Foo';
import type Bar from 'Bar';
type T = Foo;
const x: Bar = 1;
Open in PlaygrounddisallowTypeAnnotations
If true
, type imports in type annotations (import()
) are not allowed.
Default is true
.
Examples of incorrect code with {disallowTypeAnnotations: true}
:
type T = import('Foo').Foo;
const x: import('Bar') = 1;
Open in PlaygroundUsage with emitDecoratorMetadata
The emitDecoratorMetadata
compiler option changes the code the TypeScript emits. In short - it causes TypeScript to create references to value imports when they are used in a type-only location. If you are using emitDecoratorMetadata
then our tooling will require additional information in order for the rule to work correctly.
If you are using type-aware linting, then you just need to ensure that the tsconfig.json
you've configured for parserOptions.project
has emitDecoratorMetadata
turned on. Otherwise you can explicitly tell our tooling to analyze your code as if the compiler option was turned on by setting parserOptions.emitDecoratorMetadata
to true
.
When Not To Use It
- If you specifically want to use both import kinds for stylistic reasons, you can disable this rule.
Related To
no-import-type-side-effects
import/consistent-type-specifier-style
import/no-duplicates
with{"prefer-inline": true}