oxc-project/oxc · error · OxcDiagnostic
Require statement not part of import statement.
Error message
Require statement not part of import statement.
What it means
Raised by typescript/no_var_requires when a `require(...)` call (a global CommonJS require, per is_global_require_call) is assigned to a variable via `var`/`let`/`const` or otherwise used outside an import statement. At the throw site the code mixes CommonJS require into a TS module where TypeScript conventions (and `import = require` for types) apply; plain require bypasses type resolution and module semantics. no_var_requires_diagnostic fires from run() for each standalone require-call assignment.
Source
Thrown at crates/oxc_linter/src/rules/typescript/no_var_requires.rs:9
use oxc_ast::AstKind;
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::{GetSpan, Span};
use crate::{AstNode, ast_util::is_global_require_call, context::LintContext, rule::Rule};
fn no_var_requires_diagnostic(span: Span) -> OxcDiagnostic {
OxcDiagnostic::warn("Require statement not part of import statement.")
.with_help("Use ES module imports or `import = require` instead.")
.with_label(span)
}
#[derive(Debug, Default, Clone)]
pub struct NoVarRequires;
declare_oxc_lint!(
/// ### What it does
///
/// Disallow `require` statements except in import statements.
///
/// **NOTE**: This rule is intentionally missing the `allow` option from the original typescript-eslint rule.
/// This rule is deprecated in the upstream plugin and the `typescript/no-require-imports` rule should be
/// used instead.
///
/// ### Why is this bad?
///View on GitHub (pinned to e1e7af627c)
Solutions
- Use `import fs from "fs"` instead.
- For types-only imports needing the pattern, use `import x = require("...")`.
Defensive patterns
Strategy: validation
When it happens
Trigger: Thrown at crates/oxc_linter/src/rules/typescript/no_var_requires.rs:9 when the library encounters an invalid state.
Common situations: See trigger scenarios.
AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20).
Data as JSON: /api/errors/7155141fbb11f39b.
Report an issue: GitHub.