oxc-project/oxc · error

{module_name:?} also has a named export {export_name:?}

Error message

{module_name:?} also has a named export {export_name:?}

What it means

Diagnostic from the oxlint rule import/no-named-as-default-member (suspicious category). It fires when a property is read off a default import and that property is a named export of the same module: given bar.js exports `function bar()` and a default, writing `import foo from './bar'; foo.bar` yields undefined at runtime — the named export does not live on the default. The help text prints the exact intended import, e.g. `import { bar } from './bar'`. This is one of the few style-adjacent rules that catches a real runtime bug.

Source

Thrown at crates/oxc_linter/src/rules/import/no_named_as_default_member.rs:19

use oxc_ast::{
    AstKind,
    ast::{BindingPattern, Expression, IdentifierReference},
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_semantic::SymbolId;
use oxc_span::{GetSpan, Span};
use rustc_hash::FxHashMap;

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

fn no_named_as_default_member_diagnostic(
    span: Span,
    module_name: &str,
    export_name: &str,
    suggested_module_name: &str,
) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("{module_name:?} also has a named export {export_name:?}"))
        .with_help(format!("Check if you meant to write `import {{ {export_name} }} from {suggested_module_name:?}`"))
        .with_label(span)
}

// <https://github.com/import-js/eslint-plugin-import/blob/v2.29.1/docs/rules/no-named-as-default-member.md>
#[derive(Debug, Default, Clone)]
pub struct NoNamedAsDefaultMember;

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Reports the use of an exported name (named export) as a property on the
    /// default export. This occurs when trying to access a named export through
    /// the default export, which is incorrect.
    ///
    /// ### Why is this bad?
    ///
    /// Accessing a named export via the default export is incorrect and will not

View on GitHub (pinned to e1e7af627c)

Solutions

  1. Import the named export directly: `import { bar } from './bar'` (exactly what the help string prints)
  2. If you need both: `import foo, { bar } from './bar'` and use `bar` directly
  3. If the default genuinely has that property AND the module named-exports the same thing, pick one deliberately and delete the ambiguous member access

Example fix

// bar.js
export function bar() { return null }
export default () => { return 1 }

// before
import foo from './bar';
const bar = foo.bar; // undefined at runtime

// after
import { bar } from './bar';
Defensive patterns

Strategy: validation

Validate before calling

// npx oxlint src  (rule is in the default suspicious set)
// Optional runtime assert during migration:
// if (typeof foo.bar === 'undefined') throw new Error('foo.bar missing — did you mean import { bar }?');

Type guard

// narrows before use when the member genuinely exists on the default
const hasBar = (v: unknown): v is { bar: () => unknown } =>
  typeof v === 'object' && v !== null && 'bar' in v;

Prevention

When it happens

Trigger: A default-import binding (resolved to a root symbol) is the object of a static member expression whose property name is in the remote module's exported_bindings — crates/oxc_linter/src/rules/import/no_named_as_default_member.rs:19 reports the whole `foo.bar` span. Classic case: `import React from './react'; React.Component` or `import Moment from 'moment'; Moment.moment`.

Common situations: Libraries that expose both a default object and named exports (moment, axios-style SDKs); copy-paste from docs that used namespace imports; refactors where a named export was newly added and old member access now resolves to undefined.

Related errors


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