oxc-project/oxc · warning · OxcDiagnostic

TypeScript will only remove the inline type specifiers which

Error message

TypeScript will only remove the inline type specifiers which will leave behind a side effect import at runtime.

What it means

Oxlint's no-import-type-side-effects: for `import { type A } from 'mod'`, TypeScript erases only the inline type specifiers, leaving `import {} from 'mod'` behind as a runtime side-effect module load. The warn text at no_import_type_side_effects.rs:18 states this exactly, and the rule's help recommends the top-level `type` qualifier so the whole statement is removed. The rule registers a Fix (see the Fix import at no_import_type_side_effects.rs:10) to rewrite the statement automatically.

Source

Thrown at crates/oxc_linter/src/rules/typescript/no_import_type_side_effects.rs:17

use oxc_ast::{
    AstKind,
    ast::{ImportDeclarationSpecifier, ImportOrExportKind},
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::{GetSpan, Span};

use crate::{
    AstNode,
    context::{ContextHost, LintContext},
    fixer::Fix,
    rule::Rule,
};

fn no_import_type_side_effects_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("TypeScript will only remove the inline type specifiers which will leave behind a side effect import at runtime.")
        .with_help("Convert this to a top-level type qualifier to properly remove the entire import.")
        .with_label(span)
}

#[derive(Debug, Default, Clone)]
pub struct NoImportTypeSideEffects;

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Enforce the use of top-level `import type` qualifier when an import only
    /// has specifiers with inline type qualifiers.
    ///
    /// ### Why is this bad?
    ///
    /// The `--verbatimModuleSyntax` compiler option causes TypeScript to do
    /// simple and predictable transpilation on import declarations.  Namely, it
    /// completely removes import declarations with a top-level type qualifier,

View on GitHub (pinned to e1e7af627c)

Solutions

Rewrite to `import type { Config, Options } from './types';`
Run `oxlint --fix`; the rule ships an auto-fix for this rewrite
Keep at least one value specifier if the module genuinely must load for side effects

Example fix

// before
import { type Config, type Options } from './types';

// after
import type { Config, Options } from './types';

Defensive patterns

Strategy: validation

Validate before calling

npx oxlint --fix .   # the rule ships a fixer for this exact rewrite
npx oxlint --deny-warnings .

Prevention

Enable verbatimModuleSyntax in tsconfig; the compiler then enforces the same discipline
Adopt the habit: if every specifier is a type, the `type` goes on the import itself
Run oxlint --fix in pre-commit so inline-type-only imports are rewritten automatically

When it happens

Trigger: An import declaration where every specifier uses the inline `type` keyword, e.g. `import { type Config, type Options } from './types';`.

Common situations: Codebases using verbatimModuleSyntax or isolatedModules, refactors that inline-qualified all specifiers one by one, bundler tree-shaking regressions traced to leftover side-effect imports.

Related errors

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