oxc-project/oxc · warning · OxcDiagnostic

Prefer using inline type specifiers instead of a top-level t

Error message

Prefer using inline type specifiers instead of a top-level type-only import.

What it means

The `prefer-inline` mode of `import/consistent-type-specifier-style`: type-only imports should use inline `{ type Foo }` specifiers rather than a top-level `import type` statement (declaration-file imports excepted — they always require top-level). The rule's fixer can rewrite the statement into the inline form.

Source

Thrown at crates/oxc_linter/src/rules/import/consistent_type_specifier_style.rs:47

    .with_label(span)
}

fn consistent_type_specifier_style_diagnostic(span: Span, mode: &Mode) -> OxcDiagnostic {
    let (warn_msg, help_msg) = match mode {
        Mode::Inline => (
            "Prefer using inline type specifiers instead of a top-level type-only import.",
            "Replace top‐level import type with an inline type specifier.",
        ),
        Mode::TopLevel => (
            "Prefer using a top-level type-only import instead of inline type specifiers.",
            "Replace inline type specifiers with a top‐level import type statement.",
        ),
        Mode::TopLevelIfOnlyTypeImports => (
            "Prefer using a top-level type-only import instead of inline type specifiers when there are only type imports.",
            "Replace inline type specifiers with a top‐level import type statement.",
        ),
    };
    OxcDiagnostic::warn(warn_msg).with_help(help_msg).with_label(span)
}

#[derive(Debug, Default, PartialEq, Clone, Serialize, Deserialize, JsonSchema)]
enum Mode {
    /// Prefer `import type { Foo } from 'foo'` for type imports.
    #[default]
    #[serde(rename = "prefer-top-level")]
    TopLevel,
    /// Prefer `import { type Foo } from 'foo'` for type imports.
    #[serde(rename = "prefer-inline")]
    Inline,
    /// Prefer `import type { Foo } from 'foo'` when all named imports are types, but allow
    /// `import { type Foo, bar } from 'foo'` when value imports are present.
    #[serde(rename = "prefer-top-level-if-only-type-imports")]
    TopLevelIfOnlyTypeImports,
}

#[derive(Debug, Default, Clone, Serialize, Deserialize)]

View on GitHub (pinned to e1e7af627c)

Solutions

1. Change to `import { type Foo } from 'foo';`
2. Merge the type specifier into an existing value import from the same module: `import { bar, type Foo } from 'foo';`
3. Apply `oxlint --fix` for a repo-wide conversion

Example fix

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

// after
import { type Foo, bar } from 'foo';

// .oxlintrc.json
{
  "plugins": ["import"],
  "rules": { "import/consistent-type-specifier-style": ["warn", "prefer-inline"] }
}
// CI gate: npx oxlint src/

When it happens

Trigger: Rule configured as `["error", "prefer-inline"]` and code containing `import type { Foo } from 'foo';` where the imported source is not a declaration file.

Common situations: Teams standardizing on inline specifiers to keep type and value imports from one module in a single statement; configs migrated away from the prefer-top-level default; codemods that emit top-level import type into an inline-style repo.

Related errors

• Prefer using a top-level type-only import instead of inline
• Prefer using a top-level type-only import instead of inline
• Type imports from declaration files must use top-level `impo
• Export statements should appear at the end of the file
• Type can be trivially inferred from the initializer

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