oxc-project/oxc · error · OxcDiagnostic

No default export found in imported module {imported_name:?}

Error message

No default export found in imported module {imported_name:?}

What it means

oxlint's `import/default` rule (port of eslint-plugin-import): when a statement requests a default import (`ImportImportName::Default`), the linter resolves the target module within the same lint run (validating its extension via VALID_EXTENSIONS) and inspects its module record; if no default export entry exists there, this diagnostic names the offending module specifier.

Source

Thrown at crates/oxc_linter/src/rules/import/default.rs:8

use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::{Span, VALID_EXTENSIONS};

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

fn default_diagnostic(imported_name: &str, span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("No default export found in imported module {imported_name:?}"))
        .with_help(format!("Does {imported_name:?} have the default export?"))
        .with_label(span)
}

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

declare_oxc_lint!(
    /// ### What it does
    ///
    /// If a default import is requested, this rule will report if there is no
    /// default export in the imported module.
    ///
    /// ### Why is this bad?
    ///
    /// Using a default import when there is no default export can lead to
    /// confusion and runtime errors. It can make the code harder to understand

View on GitHub (pinned to a3d33dda7c)

Solutions

1. Change the importer to a named import: `import { foo } from './bar';`
2. Add `export default Foo;` to the target module if a default export is genuinely intended
3. For CommonJS targets, import the namespace (`import * as util from './util'`) or align tsconfig esModuleInterop/allowSyntheticDefaultImports with how the code imports
4. Keep the imported file inside the directories oxlint lints so cross-module resolution can see its exports

Example fix

// before — bar.ts has only named exports
// bar.ts: export function foo() {}
import foo from './bar';

// after
import { foo } from './bar';

// dual static gates catch missing default exports before runtime
// 1) TypeScript with real module resolution
//    npx tsc --noEmit
// 2) oxlint with the import plugin
// .oxlintrc.json: { "plugins": ["import"], "rules": { "import/default": "error" } }
//    npx oxlint src/

When it happens

Trigger: `import Foo from './bar';` where bar.ts contains only named exports; `import util from './util'` where util.cjs assigns `module.exports = { a, b }` with no recognizable default; also behaves differently when the target file is outside the linted paths so its module record is unavailable.

Common situations: A refactor replacing `export default` with named exports without updating importers; barrel index files that only re-export names; TypeScript compiled without esModuleInterop-style interop; moving files so the specifier now hits a different module.

Related errors

• No named exports found in module '{module_name}'
• Type imports from declaration files must use top-level `impo
• Prefer using inline type specifiers instead of a top-level t
• Prefer using a top-level type-only import instead of inline
• Prefer using a top-level type-only import instead of inline

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