oxc-project/oxc · warning

'{module_name}' export is duplicated

Error message

'{module_name}' export is duplicated

What it means

This diagnostic comes from the same `no_duplicate_imports` rule, from its export branch. It fires only when the option `includeExports` is set to `true`. It reports a re-export from a module (`export ... from 'm'`) when the file also imports from that module, or a duplicate export of the same name. The report labels the export and the earlier statement it collides with.

Source

Thrown at crates/oxc_linter/src/rules/eslint/no_duplicate_imports.rs:34

fn no_duplicate_imports_diagnostic(
    module_name: &str,
    span: Span,
    previous_span: Span,
) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("'{module_name}' import is duplicated"))
        .with_help("Merge the duplicated import into a single import statement")
        .with_labels([
            span.label("This import is duplicated"),
            previous_span.label("Can be merged with this import"),
        ])
}

fn no_duplicate_exports_diagnostic(
    module_name: &str,
    span: Span,
    previous_span: Span,
) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("'{module_name}' export is duplicated"))
        .with_help("Merge the duplicated exports into a single export statement")
        .with_labels([
            span.label("This export is duplicated"),
            previous_span.label("Can be merged with this"),
        ])
}

#[derive(Debug, Default, Clone, JsonSchema, Deserialize)]
#[serde(rename_all = "camelCase", default, deny_unknown_fields)]
pub struct NoDuplicateImports {
    /// When `true` this rule will also look at exports to see if there is both a re-export of a
    /// module as in `export ... from 'module'` and also a standard import statement for the same
    /// module. This would count as a rule violation because there are in a sense two statements
    /// importing from the same module.
    ///
    /// Examples of **incorrect** code when `includeExports` is set to `true`:
    /// ```js
    /// import { merge } from 'module';

View on GitHub (pinned to e1e7af627c)

Solutions

  1. Keep one statement per module: import what the file uses, and re-export from a separate barrel.
  2. Rewrite as `import { helper, formatDate } from './utils.js'; export { formatDate };` so only the import touches the module.
  3. Set `includeExports` back to `false` when the overlap is intended.
  4. Suppress one line with `// oxlint-disable-next-line no-duplicate-imports`.

Example fix

// before
import { helper } from './utils.js';
export { formatDate } from './utils.js';

// after
import { helper, formatDate } from './utils.js';
export { formatDate };
Defensive patterns

Strategy: validation

Validate before calling

// report import + re-export overlap for the same module
const imports = new Set([...src.matchAll(/import[\s\S]*?from ['"]([^'"]+)['"]/g)].map(m => m[1]));
for (const m of src.matchAll(/export\s*\{[^}]*\}\s*from ['"]([^'"]+)['"]/g)) {
  if (imports.has(m[1])) throw new Error('import and export share module ' + m[1]);
}

Prevention

When it happens

Trigger: The rule config sets `includeExports: true`, and the file contains both `import { a } from './m';` and `export { b } from './m';`. The diagnostic names the module and points at both spans.

Common situations: A barrel file (index.js) imports helpers from a module and also re-exports parts of it. An export line is added next to an import of the same module during a refactor.

Related errors


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