oxc-project/oxc · warning

Named exports are not allowed.

Error message

Named exports are not allowed.

What it means

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.

Source

Thrown at crates/oxc_linter/src/rules/import/no_named_export.rs:9

use oxc_ast::AstKind;
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::Span;

use crate::{context::LintContext, rule::Rule};

fn no_named_export_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Named exports are not allowed.")
        .with_help("Replace named exports with a single export default to ensure a consistent module entry point.")
        .with_label(span)
}

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

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Prohibit named exports.
    ///
    /// ### Why is this bad?
    ///
    /// Named exports require strict identifier matching and can lead to fragile imports,
    /// while default exports enforce a single, consistent module entry point.
    ///
    /// ### Examples

View on GitHub (pinned to e1e7af627c)

Solutions

1. Follow the policy: move the export into a single default export (`const api = { x, y }; export default api;`) and update importers
2. If named exports are actually wanted, turn the rule off ("import/no-named-export": "off") — most codebases want named exports
3. Scope the rule with path overrides to only the plugin/extension directories that need the single-default contract

Example fix

// before
export const greet = () => "hi";
export const leave = () => "bye";

// after
const api = { greet: () => "hi", leave: () => "bye" };
export default api;

// .oxlintrc.json — apply the policy only where it belongs
{ "rules": { "import/no-named-export": "off" },
  "overrides": [{ "files": ["src/plugins/**"], "rules": { "import/no-named-export": "error" } }] }

When it happens

Trigger: 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.

Common situations: 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.

Related errors

• Prefer named exports
• Module {export_name:?} has named export {module_name:?}
• {module_name:?} also has a named export {export_name:?}
• Could not find the reuseWorker option in ${path}
• Do not assign to imported bindings

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