{"record":{"id":"18057a30154e1c7a","repo":"oxc-project/oxc","slug":"prefer-named-exports","errorCode":null,"errorMessage":"Prefer named exports","messagePattern":"Prefer named exports","errorType":"validation","errorClass":"OxcDiagnostic","httpStatus":null,"severity":"warning","filePath":"crates/oxc_linter/src/rules/import/no_default_export.rs","lineNumber":8,"sourceCode":"use oxc_diagnostics::OxcDiagnostic;\nuse oxc_macros::declare_oxc_lint;\nuse oxc_span::Span;\n\nuse crate::{context::LintContext, rule::Rule};\n\nfn no_default_export_diagnostic(span: Span) -> OxcDiagnostic {\n    OxcDiagnostic::warn(\"Prefer named exports\")\n        .with_help(\"Replace this default export with a named export.\")\n        .with_label(span)\n}\n\n#[derive(Debug, Default, Clone)]\npub struct NoDefaultExport;\n\ndeclare_oxc_lint!(\n    /// ### What it does\n    ///\n    /// Disallow modules from having default exports.\n    ///\n    /// This can help your editor provide better auto-import functionality, as named exports\n    /// offer more explicit and predictable imports compared to default exports.\n    ///\n    /// ### Why is this bad?\n    ///\n    /// Default exports can lead to confusion, as the name of the imported value","sourceCodeStart":1,"sourceCodeEnd":26,"githubUrl":"https://github.com/oxc-project/oxc/blob/e1e7af627c8843ab64044ed466b128fcc21a035b/crates/oxc_linter/src/rules/import/no_default_export.rs#L1-L26","documentation":"Diagnostic from the oxlint rule import/no-default-export (restriction category). It fires on every `export default ...` declaration, enforcing a named-exports-only module style. Named exports force consistent names between declaration and import sites, improve refactorings/auto-imports, and avoid the ambiguity of defaults; teams that adopt this policy turn the rule on explicitly.","triggerScenarios":"Any ExportDefaultDeclaration (`export default foo`, `export default function bar() {}`, etc.) in a file where the rule is enabled. Constructed by no_default_export_diagnostic at crates/oxc_linter/src/rules/import/no_default_export.rs:8.","commonSituations":"Teams standardizing on named exports (common in large React/TypeScript codebases and some style guides that forbid defaults); codemods converting a library's public surface to named exports; accidental enabling of the whole restriction category.","solutions":["Convert the default export to a named export and update every importer: `import Foo from './foo'` → `import { Foo } from './foo'`","Keep default exports and turn the rule off (\"import/no-default-export\": \"off\") if they are part of your API (e.g. Vue SFC default exports, CSS modules, Next.js pages)","Scope the rule to directories where the policy applies using config overrides"],"exampleFix":"// before\nconst foo = \"bar\";\nexport default foo;\n\n// after\nexport const foo = \"bar\";","handlingStrategy":"validation","validationCode":"// .oxlintrc.json — scope the policy instead of fighting it per-file\n{ \"rules\": { \"import/no-default-export\": \"off\" },\n  \"overrides\": [{ \"files\": [\"src/utils/**\"], \"rules\": { \"import/no-default-export\": \"warn\" } }] }","typeGuard":null,"tryCatchPattern":null,"preventionTips":["Decide the named-vs-default policy per project area and encode it in overrides","Use explicit `import { X }` in new code — it survives renames better than defaults","Watch for framework constraints (Vue SFC, Next.js pages) that require defaults and exclude those globs"],"tags":["lint","oxlint","imports","default-export","named-export","style-policy"],"backgroundTag":"prefer-named-exports","analyzedSha":"e1e7af627c8843ab64044ed466b128fcc21a035b","analyzedAt":"2026-08-20T07:01:07.079Z","contentChangedAt":"2026-08-20T07:01:07.079Z","schemaVersion":2},"datasetVersion":"2026-09-14T05:17:10.506Z"}