oxc-project/oxc · warning
Variables should not be deleted
Error message
Variables should not be deleted
What it means
This diagnostic comes from the `no_delete_var` rule in oxlint. The `delete` operator removes a property from an object; it cannot remove a variable binding. The rule reports a `delete` unary expression whose operand is a variable reference. In strict mode code, such a `delete` is an early syntax error, so the parser rejects it before lint even runs.
Source
Thrown at crates/oxc_linter/src/rules/eslint/no_delete_var.rs:10
use oxc_ast::AstKind;
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::Span;
use oxc_syntax::operator::UnaryOperator;
use crate::{AstNode, context::LintContext, rule::Rule};
fn no_delete_var_diagnostic(span: Span) -> OxcDiagnostic {
OxcDiagnostic::warn("Variables should not be deleted")
.with_help("Assign `undefined` to the variable instead of using `delete`. The `delete` operator is intended for removing properties from objects, not for variables.")
.with_label(span)
}
#[derive(Debug, Default, Clone)]
pub struct NoDeleteVar;
declare_oxc_lint!(
/// ### What it does
///
/// The purpose of the `delete` operator is to remove a property from an
/// object.
///
/// ### Why is this bad?
///
/// Using the `delete` operator on a variable might lead to unexpected
/// behavior.
///View on GitHub (pinned to e1e7af627c)
Solutions
- Assign `undefined` when only the value must be gone: `x = undefined;`.
- Move the data into an object and delete the property: `delete obj.x;`.
- Put the code in a block or function scope so the variable goes out of scope on its own.
- Suppress once with `// oxlint-disable-next-line no-delete-var` in non-strict legacy code.
Example fix
// before let tmp = compute(user); delete tmp; // after let tmp = compute(user); tmp = undefined;
Defensive patterns
Strategy: validation
Validate before calling
// scan sources before lint
const bad = /(^|[^.\w])delete\s+[A-Za-z_$][\w$]*\s*;/.exec(src);
if (bad) throw new Error('delete on a variable: ' + bad[0]); Prevention
- Use `delete` only on object properties.
- Prefer block or function scope over manual cleanup.
- Keep files in strict mode (ES modules are strict) so the parser rejects this pattern early.
When it happens
Trigger: A `delete` unary operator applied to an identifier that names a variable: `delete myVar;` in a sloppy-mode script. The rule matches `UnaryOperator::Delete` with an identifier operand.
Common situations: A developer with C or Python background writes `delete x` to free memory. Code copied from old pre-strict scripts. A refactor moves code into an ES module, where strict mode makes the line a hard parse error.
Related errors
- `debugger` statement is not allowed
- A regular expression literal can be confused with '/='.
- Duplicate class member: {member_name:?}
- Duplicate conditions in if-else-if chain
- Duplicate key '{key}'
AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20).
Data as JSON: /api/errors/0274fb46e3a6ef2f.
Report an issue: GitHub.