oxc-project/oxc · warning

Suggest using the built-in equality matchers.

Error message

Suggest using the built-in equality matchers.

What it means

This is the oxlint `prefer-equality-matcher` rule (jest/vitest plugin). It flags `expect(a === b).toBe(true)`-style assertions and offers an autofix (`FixKind` fixer is imported) that rewrites them to the built-in equality matchers `toEqual`/`toStrictEqual`/`toBe`. The generic boolean form produces the unhelpful failure message 'expected true to be false', while the equality matcher prints an actual value diff.

Source

Thrown at crates/oxc_linter/src/rules/shared/jest_vitest/prefer_equality_matcher.rs:16

use oxc_ast::{
    AstKind,
    ast::{Argument, BinaryExpression, Expression},
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_span::Span;
use oxc_syntax::operator::BinaryOperator;

use crate::{
    context::LintContext,
    fixer::{FixKind, RuleFixer},
    utils::{ParsedExpectFnCall, PossibleJestNode, is_equality_matcher, parse_expect_jest_fn_call},
};

fn use_equality_matcher_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Suggest using the built-in equality matchers.")
        .with_help("Prefer using one of the equality matchers instead")
        .with_label(span)
}

pub const DOCUMENTATION: &str = r"### What it does

Jest has built-in matchers for expecting equality, which allow for more readable
tests and error messages if an expectation fails.

### Why is this bad?

Testing equality expressions with generic matchers like `toBe(true)`
makes tests harder to read and understand. When tests fail, the error
messages are less helpful because they don't show what the actual values
were. Using specific equality matchers provides clearer test intent and
better debugging information.

### Examples

View on GitHub (pinned to e1e7af627c)

Solutions

1. Apply the rule's autofix (oxlint `--fix`): `expect(a === b).toBe(true)` becomes `expect(a).toBe(b)` (or toEqual for structural equality).
2. For negated comparisons, flip the matcher: `expect(a !== b).toBe(true)` → `expect(a).not.toBe(b)`.
3. For loose equality `== null`, prefer Jest's dedicated matchers: `expect(x).toBeNull()` / `toBeUndefined()` / `toBeDefined()`.

Example fix

// before
expect(cart.total === 100).toBe(true);

// after
expect(cart.total).toBe(100);

// .oxlintrc.json
{ "rules": { "jest/prefer-equality-matcher": "error" } }

npx oxlint --fix tests/  # autofix rewrites boolean equality assertions

When it happens

Trigger: The expect argument is a `BinaryOperator` equality comparison (`==`, `===`, `!=`, `!==`) and the matcher is one of `is_equality_matcher`: `toBe`, `toEqual`, or `toStrictEqual`, e.g. `expect(x == null).toBe(true)`.

Common situations: Developers coming from assert-style libraries (`assert.strictEqual`); guarding against null/undefined with `== null` wrapped in toBe(true); generated test scaffolds that mechanically wrap booleans.

Related errors

• `expect` must be inside of a test block.
• Suggest using `toBeCalledWith()` or `toHaveBeenCalledWith()`
• `{prefix}.hasAssertions` expects no arguments.
• `{prefix}.assertions` expects a single argument of type numb
• This argument should be a number.

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