What causes "Do not assign to the variable `module`." in oxc-project/oxc?

Rename the variable to something like `appModule` or `mod`.

oxc-project/oxc · warning · OxcDiagnostic

Do not assign to the variable `module`.

Error message

Do not assign to the variable `module`.

What it means

Warning from oxlint rule `nextjs/no-assign-module-variable`. Next.js bundles code with webpack, which supplies every CommonJS module with a free `module` variable (`module.exports`). Declaring or assigning your own `module` shadows that built-in and breaks module evaluation during the build. The rule flags any binding or assignment target named exactly `module`.

Source

Thrown at crates/oxc_linter/src/rules/nextjs/no_assign_module_variable.rs:9

use oxc_ast::{AstKind, ast::BindingPattern};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::Span;

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

fn no_assign_module_variable_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Do not assign to the variable `module`.")
        .with_help("See https://nextjs.org/docs/messages/no-assign-module-variable")
        .with_label(span)
}

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

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Prevents the assignment or declaration of variables named `module` in Next.js applications.
    ///
    /// ### Why is this bad?
    ///
    /// The variable name `module` is reserved in Next.js for internal use and module system
    /// functionality. Declaring your own `module` variable can conflict with Next.js's internal
    /// module system, lead to unexpected behavior in your application, and cause issues with code
    /// splitting and hot module replacement.

View on GitHub (pinned to e1e7af627c)

Solutions

Rename the variable to something like `appModule` or `mod`.
If you are wrapping CommonJS output, keep that code in a `.cjs` or server-side file outside the Next.js client lint scope.
Re-run oxlint to confirm no `module` binding remains.

Example fix

// before
const module = { exports: {} };

// after
const moduleWrapper = { exports: {} };

Defensive patterns

Strategy: validation

Validate before calling

// catch module bindings early:
// rg -n '(const|let|var|function|class)\s+module\b|^\s*module\s*=' src

Prevention

Reserve `module` as an untouchable name in Next.js code review checklists.
When porting CommonJS wrappers, rename `module`/`exports` immediately during the port.
Enable the nextjs oxlint plugin in CI to catch the binding before webpack fails the build.

When it happens

Trigger: Any declaration (`var`/`let`/`const`/`function`/`class`), import binding, or assignment such as `module = ...` that introduces or writes a variable named `module`.

Common situations: Porting Node-style code that wraps modules (`const module = { exports: {} }`); test helpers reusing the name; generated code that inlines a module object.

Related errors

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