oxc-project/oxc · warning

Suggest using `toStrictEqual()`.

Error message

Suggest using `toStrictEqual()`.

What it means

This warning comes from the oxlint `jest/prefer-strict-equal` rule (source: crates/oxc_linter/src/rules/shared/jest_vitest/prefer_strict_equal.rs:10). It fires when a test uses `toEqual()` for deep equality. The rule's rationale is that `toEqual()` ignores `undefined` properties in objects and arrays, which can produce passing tests that should fail, while `toStrictEqual()` also checks type and class equality.

Source

Thrown at crates/oxc_linter/src/rules/shared/jest_vitest/prefer_strict_equal.rs:10

use oxc_diagnostics::OxcDiagnostic;
use oxc_span::Span;

use crate::{
    context::LintContext,
    utils::{PossibleJestNode, parse_expect_jest_fn_call},
};

fn use_to_strict_equal(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Suggest using `toStrictEqual()`.")
        .with_help("Use `toStrictEqual()` instead")
        .with_label(span)
}

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

This rule triggers a warning if `toEqual()` is used to assert equality.

### Why is this bad?

The `toEqual()` matcher performs a deep equality check but ignores
`undefined` values in objects and arrays. This can lead to false
positives where tests pass when they should fail. `toStrictEqual()`
provides more accurate comparison by checking for `undefined` values.

### Examples

Examples of **incorrect** code for this rule:

View on GitHub (pinned to e1e7af627c)

Solutions

1. Replace `toEqual(...)` with `toStrictEqual(...)` where type-strict equality is intended: `expect(actual).toStrictEqual(expected)`.
2. Re-run the tests to confirm they still pass; if they now fail, the failure is the exact `undefined`/type mismatch the rule is warning about - fix the expectation or the production data.
3. If the looser `toEqual` semantics are intentional for that assertion, suppress inline with `// oxlint-disable-next-line jest/prefer-strict-equal` (or `/* eslint-disable */`-style comment your config maps).
4. If the whole repo wants loose equality, disable the rule in `.oxlintrc.json`: `"rules": { "jest/prefer-strict-equal": "off" }`.

Example fix

// before
expect(result).toEqual({ id: 1 });

// after
expect(result).toStrictEqual({ id: 1 });

// Pre-commit scan: find loose equality on objects before lint runs
// rg -n "\.toEqual\(" --type ts tests/ | rg -v "toStrictEqual"

When it happens

Trigger: An `expect(...)` call chained with the `toEqual()` matcher on an object, array, or class instance, e.g. `expect(actual).toEqual(expected)`. The rule is part of the jest/vitest plugin in oxlint, so it fires when that plugin is enabled (e.g. `oxlint --jest` or a `.oxlintrc.json` with the jest plugin and this rule turned on).

Common situations: Teams migrating from ESLint's eslint-plugin-jest to oxlint and re-enabling stricter preset rules; test suites that assert on partially-built objects where `undefined` vs missing keys matters; CI pipelines that run `oxlint` with `--deny-warnings` so this warning fails the build.

Related errors

• Suggest using the built-in equality matchers.
• Use `toBe` when expecting primitive literals.
• Use `toBeUndefined` instead.
• Use `toBeDefined` instead.
• Use `toBeNull` instead.

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