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
- Keep one statement per module: import what the file uses, and re-export from a separate barrel.
- Rewrite as `import { helper, formatDate } from './utils.js'; export { formatDate };` so only the import touches the module.
- Set `includeExports` back to `false` when the overlap is intended.
- 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
- Keep barrel files re-export-only; do the work in separate modules.
- Enable `includeExports` only when you want the strict check.
- Run 'organize imports' before each commit.
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
- '{module_name}' import is duplicated
- `debugger` statement is not allowed
- Variables should not be deleted
- A regular expression literal can be confused with '/='.
- Duplicate class member: {member_name:?}
AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20).
Data as JSON: /api/errors/60593d886d6bc6d6.
Report an issue: GitHub.