oxc-project/oxc · warning

A module importing itself is not allowed

Error message

A module importing itself is not allowed

What it means

Diagnostic from the oxlint rule import/no-self-import (suspicious category). It fires when a module imports its own resolved path — `import x from './this-same-file.js'`. A module already has direct access to its own declarations, so the import is always redundant, usually a rename/copy-paste leftover, and in CJS interop can yield an incomplete exports object. The help is blunt: remove the import.

Source

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

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

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

fn no_self_import_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("A module importing itself is not allowed")
        .with_help("Remove this import. A module should not import itself.")
        .with_label(span)
}

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

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Forbids a module from importing itself. This can sometimes happen accidentally,
    /// especially during refactoring.
    ///
    /// ### Why is this bad?
    ///
    /// Importing a module into itself creates a circular dependency, which can cause
    /// runtime issues, including infinite loops, unresolved imports, or `undefined` values.
    ///

View on GitHub (pinned to e1e7af627c)

Solutions

1. Delete the self-importing statement; reference the local declarations directly
2. After renames, search the file for its own old basename and clean the leftovers
3. Audit tsconfig/bundler aliases for mappings that resolve a specifier back onto the same file

Example fix

// before (config.ts)
import { defaultConfig } from './config'; // same file
export const defaultConfig = { env: 'prod' };

// after (config.ts)
export const defaultConfig = { env: 'prod' };

// npx madge --circular --extensions js,ts src/
// rg -n "from\\s+['\"]\\./index" -g 'index.*'  (barrel self-imports)

When it happens

Trigger: The module record's own loaded modules contain one whose resolved absolute path equals the importing file's path — reported from no_self_import_diagnostic at crates/oxc_linter/src/rules/import/no_self_import.rs:8. Typical producers: `import { foo } from './index'` inside index.ts, stale filenames after a rename, and duplicated files that kept their original imports.

Common situations: File copies used as templates (`cp user.dto.ts account.dto.ts` keeping `import { userSchema } from './user.dto'`); renames where the old name still resolves to the same file via alias or case-insensitive filesystems; barrel files importing themselves.

Related errors

• Dependency cycle detected
• Unexpected empty named `import` block.
• Could not find the reuseWorker option in ${path}
• Unexpected constant {lhs_name} on the left-hand side of a {e
• Unexpected constant binary expression

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