{"record":{"id":"274e64adf37c5aa2","repo":"oxc-project/oxc","slug":"named-exports-are-not-allowed","errorCode":null,"errorMessage":"Named exports are not allowed.","messagePattern":"Named exports are not allowed\\.","errorType":"console","errorClass":null,"httpStatus":null,"severity":"warning","filePath":"crates/oxc_linter/src/rules/import/no_named_export.rs","lineNumber":9,"sourceCode":"use oxc_ast::AstKind;\nuse oxc_diagnostics::OxcDiagnostic;\nuse oxc_macros::declare_oxc_lint;\nuse oxc_span::Span;\n\nuse crate::{context::LintContext, rule::Rule};\n\nfn no_named_export_diagnostic(span: Span) -> OxcDiagnostic {\n    OxcDiagnostic::warn(\"Named exports are not allowed.\")\n        .with_help(\"Replace named exports with a single export default to ensure a consistent module entry point.\")\n        .with_label(span)\n}\n\n#[derive(Debug, Default, Clone)]\npub struct NoNamedExport;\n\ndeclare_oxc_lint!(\n    /// ### What it does\n    ///\n    /// Prohibit named exports.\n    ///\n    /// ### Why is this bad?\n    ///\n    /// Named exports require strict identifier matching and can lead to fragile imports,\n    /// while default exports enforce a single, consistent module entry point.\n    ///\n    /// ### Examples","sourceCodeStart":1,"sourceCodeEnd":27,"githubUrl":"https://github.com/oxc-project/oxc/blob/e1e7af627c8843ab64044ed466b128fcc21a035b/crates/oxc_linter/src/rules/import/no_named_export.rs#L1-L27","documentation":"Diagnostic from the oxlint rule import/no-named-export (style category). It fires on named exports — `export const x`, `export function f`, `export { y }` — enforcing a policy where each module exposes a single default export as its entry point. The help suggests replacing named exports with one `export default`, typically to force a consistent module API. This is an opt-in policy rule, not a correctness check.","triggerScenarios":"Any named export declaration or named export specifier in a file where the rule is enabled. Constructed by no_named_export_diagnostic at crates/oxc_linter/src/rules/import/no_named_export.rs:9.","commonSituations":"Plugin/extension systems where each module must default-export one implementation (lint rules, webpack loaders, strategy modules); teams standardizing on default-only APIs; accidentally enabling the rule repo-wide when it was meant for one directory.","solutions":["Follow the policy: move the export into a single default export (`const api = { x, y }; export default api;`) and update importers","If named exports are actually wanted, turn the rule off (\"import/no-named-export\": \"off\") — most codebases want named exports","Scope the rule with path overrides to only the plugin/extension directories that need the single-default contract"],"exampleFix":"// before\nexport const greet = () => \"hi\";\nexport const leave = () => \"bye\";\n\n// after\nconst api = { greet: () => \"hi\", leave: () => \"bye\" };\nexport default api;","handlingStrategy":"validation","validationCode":"// .oxlintrc.json — apply the policy only where it belongs\n{ \"rules\": { \"import/no-named-export\": \"off\" },\n  \"overrides\": [{ \"files\": [\"src/plugins/**\"], \"rules\": { \"import/no-named-export\": \"error\" } }] }","typeGuard":null,"tryCatchPattern":null,"preventionTips":["Reserve this policy for plugin/strategy directories with a single-default contract","Document the intended module API shape (default vs named) in the folder README","Revisit the rule when a module legitimately needs multiple exports — usually the policy, not the code, should move"],"tags":["lint","oxlint","imports","named-export","style-policy","api-design"],"backgroundTag":"enforce-default-export-policy","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"}