oxc-project/oxc · warning

Require a message for {matcher_name:?}.

Error message

Require a message for {matcher_name:?}.

What it means

Diagnostic from oxlint's shared jest/vitest require-to-throw-message rule. `toThrow()` / `toThrowError()` with no argument passes for ANY thrown value, so the test neither pins the failure mode nor explains intent; when it breaks you cannot tell whether the right error occurred. The rule reports argument-less toThrow/toThrowError matchers on parsed `expect(...)` calls and asks for a message, and formats the matcher name into both the message and help.

Source

Thrown at crates/oxc_linter/src/rules/shared/jest_vitest/require_to_throw_message.rs:11

use oxc_ast::AstKind;
use oxc_diagnostics::OxcDiagnostic;
use oxc_span::Span;

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

fn require_to_throw_message_diagnostic(matcher_name: &str, span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("Require a message for {matcher_name:?}."))
        .with_help(format!("Add an error message to {matcher_name:?}"))
        .with_label(span)
}

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

This rule triggers a warning if `toThrow()` or `toThrowError()` is used without an error message.

### Why is this bad?

Using `toThrow()` or `toThrowError()` without specifying an expected error message
makes tests less specific and harder to debug. When a test only checks that an
error was thrown but not what kind of error, it can pass even when the wrong
error is thrown, potentially hiding bugs. Providing an expected error message
or error type makes tests more precise and helps catch regressions more effectively.

### Examples

View on GitHub (pinned to e1e7af627c)

Solutions

1. Assert the specific failure: pass a substring, regex, or error class — `.toThrow('Unable to parse input')`, `.toThrow(TypeError)`, `.toThrow(/^Invalid/)`.
2. For async rejects, keep the argument on `.rejects.toThrow('...')`.
3. If matching any error is genuinely intended, disable the rule for that line (`// oxlint-disable-next-line jest/require-to-throw-message`).

Example fix

// before
expect(() => parse(badInput)).toThrow();

// after
expect(() => parse(badInput)).toThrow('Unable to parse input');

oxlint --jest-plugin test/ # require-to-throw-message

When it happens

Trigger: A jest/vitest expect chain ending in `.toThrow()` or `.toThrowError()` with zero arguments: `expect(() => parse(bad)).toThrow();`, `await expect(fetch()).rejects.toThrowError();`. Passing a string, regex, class, or object (e.g. `{ message: 'Invalid input' }`) clears the rule.

Common situations: Placeholder assertions written to make a suite pass; teams inheriting suites where errors are unspecified; deleting a message during refactor; a11y of failure output — CI logs that just say 'thrown' without which error.

Related errors

• Test must end with an assertion
• Every test should have either `{prefix}.assertions(<number o
• Unexpected conditional expect
• Use of `{method_name}` is not allowed
• `expect` must be inside of a test block.

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