oxc-project/oxc · error · OxcDiagnostic
Right-hand side of `&&` operator has no effect.
Error message
Right-hand side of `&&` operator has no effect.
What it means
The mirror variant of `oxc/const-comparisons`: in an `&&` chain of same-direction constant comparisons on one variable, the RIGHT comparison is implied by the left — if the left is true, the right is always true — so the right operand of `&&` has no effect. The rule's doc example is `status_code < 200 && status_code <= 299`, which is simply `status_code < 200`.
Source
Thrown at crates/oxc_linter/src/rules/oxc/const_comparisons.rs:25
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::{GetSpan, Span};
use oxc_syntax::operator::{BinaryOperator, LogicalOperator};
use crate::{AstNode, context::LintContext, rule::Rule, utils::is_same_expression};
fn redundant_left_hand_side(left_span: Span, right_span: Span, help: String) -> OxcDiagnostic {
OxcDiagnostic::warn("Left-hand side of `&&` operator has no effect.")
.with_help(help)
.with_labels([
right_span.label("If this evaluates to `true`"),
left_span.label("This will always evaluate to true."),
])
}
fn redundant_right_hand_side(right_span: Span, left_span: Span, help: String) -> OxcDiagnostic {
OxcDiagnostic::warn("Right-hand side of `&&` operator has no effect.")
.with_help(help)
.with_labels([
left_span.label("If this evaluates to `true`"),
right_span.label("This will always evaluate to true."),
])
}
fn impossible(span: Span, span1: Span, x2: &str, x3: &str, x4: &str) -> OxcDiagnostic {
OxcDiagnostic::warn("Unexpected constant comparison").with_help(x4.to_string()).with_labels([
span.label(format!("Requires that {x2}")),
span1.label(format!("Requires that {x3}")),
])
}
fn constant_comparison_diagnostic(
span: Span,
evaluates_to: bool,
help: String,View on GitHub (pinned to e1e7af627c)
Solutions
- Remove the weaker right comparison and keep the stricter left one: `status_code < 200`
- If a wider range was intended (e.g. all of 2xx), write `status_code >= 200 && status_code < 300`
- Add boundary unit tests at the exact constants to lock in the intended range
Example fix
// before const ok = status_code < 200 && status_code <= 299; // after const ok = status_code < 200; // or, if the full 2xx range was intended: // const ok = status_code >= 200 && status_code < 300;
Defensive patterns
Strategy: validation
Validate before calling
// .oxlintrc.json — correctness rule (on in the default category set)
{
"rules": { "oxc/const-comparisons": "error" }
}
// CLI: npx oxlint src/ Prevention
- Write range checks as `x >= lo && x < hi` and delete any leftover weaker bound
- Boundary-test both endpoints of every range constant
- Let oxlint flag overlapping same-direction comparisons before merge
When it happens
Trigger: `status_code < 200 && status_code <= 299`; `n > 10 && n > 5`; any same-direction pair on one variable where the left bound is the stricter one.
Common situations: HTTP status range checks (2xx/4xx) written with overlapping bounds; threshold checks tightened on one side only; leftover comparisons after requirements changed.
Related errors
- Left-hand side of `&&` operator has no effect.
- Unexpected constant comparison
- Unexpected object literal comparison.
- Both sides of the logical operator are the same
- Both sides of the logical operator are equivalent
AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20).
Data as JSON: /api/errors/557744a4104f382a.
Report an issue: GitHub.