oxc-project/oxc · warning · OxcDiagnostic

`import()` type annotations are forbidden.

Error message

`import()` type annotations are forbidden.

What it means

Oxlint's typescript/consistent-type-imports rule reports this when it visits a TSImportType node, i.e. a type written as import('module').Name, while disallowTypeAnnotations is enabled (the default). The rule wants type references to come from static `import type` declarations instead, because import() types hide dependencies from bundlers and are not erased as reliably. It is the oxlint port of @typescript-eslint/consistent-type-imports' disallowTypeAnnotations option.

Source

Thrown at crates/oxc_linter/src/rules/typescript/consistent_type_imports.rs:27

    ast::{
        ImportDeclaration, ImportDeclarationSpecifier, ImportDefaultSpecifier,
        ImportNamespaceSpecifier, ImportSpecifier, Statement,
    },
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_semantic::{Reference, SymbolId};
use oxc_span::{GetSpan, Span};

use crate::{
    AstNode,
    context::{ContextHost, LintContext},
    fixer::{RuleFix, RuleFixer},
    rule::{DefaultRuleConfig, Rule},
};

fn no_import_type_annotations_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("`import()` type annotations are forbidden.")
        .with_help("Replace `import()` type annotations with a regular type import. For example, change `type T = import('module').Type` to `import type { Type } from 'module'; type T = Type`.")
        .with_label(span)
}

fn avoid_import_type_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Use an `import` instead of an `import type`.")
        .with_help("Replace the `import type` declaration with a regular `import` declaration. For example, `import type { Type } from 'module'` would become `import { Type } from 'module'`.")
        .with_label(span)
}
fn type_over_value_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("All imports in the declaration are only used as types. Use `import type`.")
        .with_help("Replace the `import` declaration with `import type`. For example, change `import { Type } from 'module'` would become `import type { Type } from 'module'`.")
        .with_note("Using `import type` for type-only imports helps with tree-shaking, makes it clear that these imports don't affect runtime code, and can improve build performance by allowing bundlers to eliminate unused type imports.")
        .with_label(span)
}

fn some_imports_are_only_types_diagnostic(span: Span, type_imports: &str) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("Imports {type_imports} are only used as type.")).with_label(span)

View on GitHub (pinned to e1e7af627c)

Solutions

  1. Rewrite `type T = import('./mod').Foo;` as `import type { Foo } from './mod';` and use `Foo` directly
  2. If the import() annotation must stay (e.g. legacy circular type reference), set "disallowTypeAnnotations": false in the rule options
  3. Suppress the single occurrence with an `// oxlint-disable-next-line typescript/consistent-type-imports` comment

Example fix

// before
type Config = import('./config').UserConfig;

// after
import type { UserConfig } from './config';
type Config = UserConfig;
Defensive patterns

Strategy: validation

Validate before calling

// .oxlintrc.json — keep the guard on but make the policy explicit
{
  "rules": {
    "typescript/consistent-type-imports": ["warn", { "disallowTypeAnnotations": true }]
  }
}

// pre-commit gate: fail fast before import() types land
// npx oxlint --type-aware-appropriate categories run in CI

Prevention

When it happens

Trigger: Linting a TypeScript file where a type position uses the import() form: `type T = import('./mod').Foo;`, `let x: import('mod').T`, or a function returning `import('mod').Type`, with the rule enabled and disallowTypeAnnotations true (default). The diagnostic fires directly from AstKind::TSImportType in the rule's run().

Common situations: Code ported from projects that used import() types to break circular type dependencies; types copied out of generated .d.ts files into app sources; enabling a stricter typescript category or migrating an existing @typescript-eslint config to oxlint without reviewing this option.

Understand the failure class

Related errors


AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/29c6e042e2f44c57. Report an issue: GitHub.