oxc-project/oxc · warning · OxcDiagnostic

Use an `import` instead of an `import type`.

Error message

Use an `import` instead of an `import type`.

What it means

Emitted by typescript/consistent-type-imports when the rule is configured with "prefer": "no-type-imports" and the file contains an `import type` declaration. Under that convention types must travel through regular value imports, so any type-only import declaration (or a specifier carrying the inline `type` modifier) is reported. The run() checks ImportDeclaration and its specifiers whenever prefer is Prefer::NoTypeImports.

Source

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

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)
}

#[derive(Debug, Default, Clone, Deserialize)]
pub struct ConsistentTypeImports(Box<ConsistentTypeImportsConfig>);

impl Deref for ConsistentTypeImports {

View on GitHub (pinned to e1e7af627c)

Solutions

1. Change `import type { Foo } from './foo';` to `import { Foo } from './foo';` and drop inline `type` modifiers
2. If the repo actually prefers type-only imports, set "prefer": "type-imports" (the default) instead
3. Override the rule only for the affected paths via oxlint config overrides, or disable it for that file with an oxlint-disable comment

Example fix

// before
import type { Foo } from './foo';

// after
import { Foo } from './foo';

// Decide the convention once and encode it, so the diagnostic is expected:
// .oxlintrc.json
{
  "rules": {
    "typescript/consistent-type-imports": ["warn", { "prefer": "no-type-imports" }]
  }
}

When it happens

Trigger: A .oxlintrc.json sets "typescript/consistent-type-imports": ["error", { "prefer": "no-type-imports" }] and the source has `import type { Foo } from './foo';` or `import { type Foo } from './foo';`. Each such declaration or type-marked specifier produces this diagnostic.

Common situations: Migrating an ESLint config where a sub-project chose no-type-imports; mixing teams with different verbatimModuleSyntax settings; auto-fixers or editors inserting `import type` while the repo convention forbids it.

Related errors

• `import()` type annotations are forbidden.
• All imports in the declaration are only used as types. Use `
• Imports {type_imports} are only used as type.
• Could not find the reuseWorker option in ${path}
• encountered allocation error

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