oxc-project/oxc · warning

Use `toBeNaN` instead.

Error message

Use `toBeNaN` instead.

What it means

Warning from the oxlint `jest/prefer-to-be` rule (source: crates/oxc_linter/src/rules/shared/jest_vitest/prefer_to_be.rs:41). The rule's run implementation checks `first_matcher_arg.is_nan()`; when an equality matcher is called with the literal `NaN`, it suggests `toBeNaN()`, which gives a precise failure message instead of a confusing deep-equality diff.

Source

Thrown at crates/oxc_linter/src/rules/shared/jest_vitest/prefer_to_be.rs:41

    OxcDiagnostic::warn("Use `toBeUndefined` instead.")
        .with_help(format!("Replace `{source_text}` with `{suggestion}`."))
        .with_label(span)
}

fn use_to_be_defined(source_text: &str, suggestion: &str, span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Use `toBeDefined` instead.")
        .with_help(format!("Replace `{source_text}` with `{suggestion}`."))
        .with_label(span)
}

fn use_to_be_null(source_text: &str, suggestion: &str, span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Use `toBeNull` instead.")
        .with_help(format!("Replace `{source_text}` with `{suggestion}`."))
        .with_label(span)
}

fn use_to_be_na_n(source_text: &str, suggestion: &str, span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Use `toBeNaN` instead.")
        .with_help(format!("Replace `{source_text}` with `{suggestion}`."))
        .with_label(span)
}

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

Recommends using `toBe` matcher for primitive literals and specific
matchers for `null`, `undefined`, and `NaN`.

### Why is this bad?

When asserting against primitive literals such as numbers and strings,
the equality matchers all operate the same, but read slightly
differently in code.

This rule recommends using the `toBe` matcher in these situations, as
it forms the most grammatically natural sentence. For `null`,
`undefined`, and `NaN` this rule recommends using their specific `toBe`

View on GitHub (pinned to e1e7af627c)

Solutions

1. Rewrite as `expect(value).toBeNaN()`.
2. Remember `toEqual(NaN)` already behaves like `toBeNaN`, so the swap is semantics-preserving - no test rework beyond the matcher name.
3. Suppress with `// oxlint-disable-next-line jest/prefer-to-be` if you must keep the original.

Example fix

// before
expect(Number('abc')).toEqual(NaN);

// after
expect(Number('abc')).toBeNaN();

// rg -n "\.toBe\(NaN\)|\.toEqual\(NaN\)" tests/ -t ts -t js

When it happens

Trigger: `expect(value).toBe(NaN)`, `expect(value).toEqual(NaN)`, or `expect(value).toStrictEqual(NaN)` - the matcher argument is the `NaN` identifier.

Common situations: Numeric-parsing tests such as `expect(Number('abc')).toEqual(NaN)`; geometry or financial code returning NaN on invalid input; suites newly linted by the jest plugin.

Related errors

• Suggest using `toStrictEqual()`.
• 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/2ab9079b66e6ca95. Report an issue: GitHub.