oxc-project/oxc · warning · OxcDiagnostic

Use of `{chain_call}` is disallowed

Error message

Use of `{chain_call}` is disallowed

What it means

Diagnostic from oxlint rule `jest/no-restricted-matchers` (shared with vitest), the restricted_chain constructor at crates/oxc_linter/src/rules/shared/jest_vitest/no_restricted_matchers.rs:21. Matchers and modifiers can be deny-listed by chain pattern (e.g. 'not', 'resolves', 'toBeTruthy'); this variant fires for a configured pattern that carries no custom message, reporting `Use of \`chain\` is disallowed` on the matcher span.

Source

Thrown at crates/oxc_linter/src/rules/shared/jest_vitest/no_restricted_matchers.rs:21

use oxc_ast::AstKind;
use oxc_diagnostics::OxcDiagnostic;
use oxc_span::Span;
use oxc_str::CompactStr;
use rustc_hash::FxHashMap;
use schemars::JsonSchema;
use serde::Deserialize;

use crate::{
    context::LintContext,
    rule::DefaultRuleConfig,
    utils::{
        JestFnKind, KnownMemberExpressionProperty, PossibleJestNode, is_type_of_jest_fn_call,
        object_with_nullable_string_schema, parse_expect_jest_fn_call,
    },
};

fn restricted_chain(chain_call: &str, span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("Use of `{chain_call}` is disallowed")).with_label(span)
}

fn restricted_chain_with_message(chain_call: &str, message: &str, span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("Use of `{chain_call}` is disallowed"))
        .with_help(message.to_string())
        .with_label(span)
}

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

Ban specific matchers & modifiers from being used, and can suggest alternatives.

### Why is this bad?

Some matchers or modifiers might be discouraged in your codebase for various reasons:
they might be deprecated, cause confusion, have performance implications, or there
might be better alternatives available. This rule allows you to enforce consistent
testing patterns by restricting certain Jest matchers and providing guidance on

View on GitHub (pinned to e1e7af627c)

Solutions

1. Replace the banned matcher with the specific alternative your team prefers, e.g. expect(x).toBe(true) instead of toBeTruthy()
2. Rewrite negations: expect(x).toBe(false) instead of expect(x).not.toBeTruthy()
3. Adjust the deny-list in .oxlintrc.json if the pattern is too broad for your codebase

Example fix

// before (config: { "toBeTruthy": null })
expect(user.isActive()).toBeTruthy();

// after
expect(user.isActive()).toBe(true);

npx oxlint -c .oxlintrc.json tests/ # no-restricted-matchers applies the configured matcher deny-list

When it happens

Trigger: A configured chain pattern (keys of the rule's map, including modifiers like `not` and full chains like `not.toBe`) is matched against the members of an expect() call parsed via parse_expect_jest_fn_call. When the entry has no message (e.g. { "toBeTruthy": null }), restricted_chain reports the joined chain text.

Common situations: Teams banning vague matchers like toBeTruthy/toBeFalsy in favor of toBe(true); banning `not` negations for readability; restricting toBeNull vs toBeUndefined confusion; enabling the rule on code that predates the convention.

Related errors

• Use of `{method_name}` is not allowed
• Unexpected alias {name:?}
• Snapshot is too long.
• {word} is not allowed in test title
• {un_prefixed_name} should match {raw_pattern}

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