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

  1. Remove the weaker right comparison and keep the stricter left one: `status_code < 200`
  2. If a wider range was intended (e.g. all of 2xx), write `status_code >= 200 && status_code < 300`
  3. 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

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


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