oxc-project/oxc · warning · OxcDiagnostic

Require or disallow "Yoda" conditions

Error message

Require or disallow "Yoda" conditions

What it means

oxlint's `yoda` rule polices operand order in comparisons between a variable and a literal. With the default `"never"` option (per `AllowYoda::Never` default) a literal-first comparison — a Yoda condition — is reported with help text telling you which side the literal is expected on; `"always"` enforces the reverse. `exceptRange` and `onlyEquality` options carve out exceptions.

Source

Thrown at crates/oxc_linter/src/rules/eslint/yoda.rs:24

    },
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_ecmascript::{ToBigInt, WithoutGlobalReferenceInformation};
use oxc_macros::declare_oxc_lint;
use oxc_span::{GetSpan, Span};
use schemars::JsonSchema;
use serde::Deserialize;

use crate::{
    AstNode,
    context::LintContext,
    rule::{Rule, TupleRuleConfig},
    utils::is_same_expression,
};

fn yoda_diagnostic(span: Span, never: bool, operator: &str) -> OxcDiagnostic {
    let expected_side = if never { "right" } else { "left" };
    OxcDiagnostic::warn("Require or disallow \"Yoda\" conditions")
        .with_help(format!("Expected literal to be on the {expected_side} side of {operator}."))
        .with_label(span)
}

#[derive(Debug, Clone, JsonSchema, Deserialize)]
#[serde(rename_all = "camelCase", default)]
pub struct Yoda(AllowYoda, YodaOptions);

#[derive(Debug, Default, Clone, JsonSchema, Deserialize)]
#[serde(rename_all = "camelCase", default, deny_unknown_fields)]
pub struct YodaOptions {
    /// If the `"exceptRange"` property is `true`, the rule *allows* yoda conditions
    /// in range comparisons which are wrapped directly in parentheses, including the
    /// parentheses of an `if` or `while` condition.
    /// A *range* comparison tests whether a variable is inside or outside the range
    /// between two literal values.
    except_range: bool,
    /// If the `"onlyEquality"` property is `true`, the rule reports yoda

View on GitHub (pinned to e1e7af627c)

Solutions

1. Swap the operands so the literal sits on the required side (default: right)
2. Allow legitimate range checks with `{ "exceptRange": true }`
3. Restrict the rule to equality operators with `{ "onlyEquality": true }`, or switch polarity to "always" if the team prefers Yoda style

Example fix

// before — Yoda condition under the default "never" option
if ("red" === color) {
  paint();
}

// after
if (color === "red") {
  paint();
}

// .oxlintrc.json
{ "rules": { "yoda": ["warn", "never", { "exceptRange": true }] } }
// CI gate: npx oxlint src/

When it happens

Trigger: Default config: `if ("red" === color)` or parenthesized range checks like `if (0 <= x && x < 1)` outside exceptRange. With `["error", "always"]`: `if (color === "red")` is reported instead.

Common situations: Code ported from old defensive C/PHP style where literal-first avoided accidental assignment (`if ("red" = color)` is a syntax error); style drift across a mixed team; enabling the rule repo-wide and cleaning up years of code.

Related errors

• Unexpected comment inline with code
• Unexpected operator assignment ({operator}) shorthand.
• Assignment (=) can be replaced with operator assignment ({op
• Use a regular expression literal instead of the `RegExp` con
• Expected '{curr_kind}' syntax before '{prev_kind}' syntax.

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