{"record":{"id":"d037439494069072","repo":"oxc-project/oxc","slug":"unexpected-use-of-undefined","errorCode":null,"errorMessage":"Unexpected use of `undefined`","messagePattern":"Unexpected use of `undefined`","errorType":"validation","errorClass":"OxcDiagnostic","httpStatus":null,"severity":"info","filePath":"crates/oxc_linter/src/rules/eslint/no_undefined.rs","lineNumber":12,"sourceCode":"use oxc_ast::AstKind;\nuse oxc_diagnostics::OxcDiagnostic;\nuse oxc_macros::declare_oxc_lint;\nuse oxc_span::Span;\n\nuse crate::{AstNode, context::LintContext, rule::Rule};\n\n#[derive(Debug, Default, Clone)]\npub struct NoUndefined;\n\nfn no_undefined_diagnostic(span: Span) -> OxcDiagnostic {\n    OxcDiagnostic::warn(\"Unexpected use of `undefined`\").with_label(span)\n}\n\ndeclare_oxc_lint!(\n    /// ### What it does\n    ///\n    /// Disallow the use of `undefined` as an identifier.\n    ///\n    /// ### Why is this bad?\n    ///\n    /// Using `undefined` directly can lead to bugs, since it can be shadowed or overwritten in JavaScript.\n    /// It's safer and more intentional to use `null` or rely on implicit `undefined` (e.g., missing return) to avoid accidental issues.\n    ///\n    /// ### Examples\n    ///\n    /// Examples of **incorrect** code for this rule:\n    /// ```javascript\n    /// var foo = undefined;\n    ///","sourceCodeStart":1,"sourceCodeEnd":30,"githubUrl":"https://github.com/oxc-project/oxc/blob/e1e7af627c8843ab64044ed466b128fcc21a035b/crates/oxc_linter/src/rules/eslint/no_undefined.rs#L1-L30","documentation":"`no-undefined` (stylistic, off by default in ESLint too) flags every use of the identifier `undefined` — comparisons, assignments, arguments. The rule's rationale: `undefined` is a writable global property in old environments and can be shadowed, so `null` or implicit undefined is held to be safer. The diagnostic is the bare message with a label, no help text.","triggerScenarios":"`if (x === undefined)`, `const y = undefined;`, `f(undefined)` — any `IdentifierReference`/binding resolving to the global `undefined` once the rule is enabled in config.","commonSituations":"Enabling the rule when adopting a strict style guide and getting hundreds of hits in existing code; teams split on `typeof x === 'undefined'` vs `x === undefined` debate; legacy ES5-era codebases that still defensively avoid the identifier.","solutions":["Prefer `x == null` (matches both null and undefined) or `x === null` where only null is meant.","Use `typeof x === 'undefined'` for globals that may not exist (it never throws).","If the identifier use is deliberate style, disable the rule in .oxlintrc.json — most modern teams do."],"exampleFix":"// before\nif (config === undefined) {\n  config = defaults;\n}\n\n// after\nif (config == null) {\n  config = defaults;\n}","handlingStrategy":"validation","validationCode":"# find all uses of the identifier before enabling the rule\nrg -n '\\bundefined\\b' src/","typeGuard":null,"tryCatchPattern":null,"preventionTips":["Use `x == null` for null-or-undefined checks.","Use `typeof x === 'undefined'` only for possibly-absent globals.","Leave this stylistic rule off unless the team explicitly wants it."],"tags":["eslint","oxlint","no-undefined","style","undefined","null-check"],"backgroundTag":"undefined-identifier-misuse","analyzedSha":"e1e7af627c8843ab64044ed466b128fcc21a035b","analyzedAt":"2026-08-20T07:01:07.079Z","contentChangedAt":"2026-08-20T07:01:07.079Z","schemaVersion":2},"datasetVersion":"2026-09-14T05:17:10.506Z"}