oxc-project/oxc · warning

{error_message:?}

Error message

{error_message:?}

What it means

Diagnostic constructor for oxlint's port of eslint-plugin-jest's no-jasmine-globals rule. It reports Jasmine-specific globals that Jest does not define, so the test crashes with a ReferenceError under Jest. Messages are per-API ('Illegal usage of jasmine global', 'Illegal usage of global spyOn', 'Illegal usage of `fail`', 'Illegal usage of `pending`', etc.) and each suggests the Jest equivalent. Note the constructor formats with `{error_message:?}` (Rust Debug), so the rendered text appears wrapped in quotes.

Source

Thrown at crates/oxc_linter/src/rules/jest/no_jasmine_globals.rs:18

use oxc_ast::{
    AstKind,
    ast::{
        AssignmentExpression, CallExpression, Expression, MemberExpression, SimpleAssignmentTarget,
    },
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::{GetSpan, Span};

use crate::{context::LintContext, rule::Rule};

fn no_jasmine_globals_diagnostic(
    error_message: &str,
    help_text: &str,
    span: Span,
) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("{error_message:?}"))
        .with_help(format!("{help_text:?}"))
        .with_label(span)
}

// <https://github.com/jest-community/eslint-plugin-jest/blob/v28.9.0/docs/rules/no-jasmine-globals.md>
#[derive(Debug, Default, Clone)]
pub struct NoJasmineGlobals;

declare_oxc_lint!(
    /// ### What it does
    ///
    /// This rule reports on any usage of Jasmine globals, which are not ported to
    /// Jest, and suggests alternatives from Jest's own API.
    ///
    /// ### Why is this bad?
    ///
    /// When migrating from Jasmine to Jest, relying on Jasmine-specific globals
    /// creates compatibility issues and prevents taking advantage of Jest's

View on GitHub (pinned to e1e7af627c)

Solutions

1. Swap the Jasmine API for its Jest equivalent: jest.spyOn (spyOn/spyOnProperty), jest.fn (createSpy), expect.extend (addMatchers), expect.any/anything/arrayContaining/objectContaining/stringMatching, jest.setTimeout (DEFAULT_TIMEOUT_INTERVAL), test.skip (pending), throw or done.fail (fail).
2. Run `oxlint --fix` to apply the automatic replacements (DEFAULT_TIMEOUT_INTERVAL and expect.* member calls).
3. Grep the suite for `jasmine.` and the four bare globals to catch stragglers in helpers/setup files.
4. If a `jasmine` identifier in your code is unrelated to the Jasmine framework, rename it or disable the rule for that file.

Example fix

// before
jasmine.DEFAULT_TIMEOUT_INTERVAL = 5000;
const spy = jasmine.createSpy('cb');
spyOn(obj, 'method');

// after
jest.setTimeout(5000);
const spy = jest.fn();
jest.spyOn(obj, 'method');

// fail the build before Jasmine globals reach CI test runs
oxlint --jest-plugin --deny-warnings test/

When it happens

Trigger: Two code shapes: (1) bare unresolved references to `spyOn`, `spyOnProperty`, `fail`, `pending` at module root scope; (2) any member access on an identifier literally named `jasmine` — calls like `jasmine.createSpy()`, `jasmine.addMatchers(m)`, `jasmine.any()`, `jasmine.clock()`, and assignments like `jasmine.DEFAULT_TIMEOUT_INTERVAL = 5000`. Auto-fix exists for `jasmine.DEFAULT_TIMEOUT_INTERVAL = <number>` (→ `jest.setTimeout(n)`) and for jasmine.any/anything/arrayContaining/objectContaining/stringMatching (→ expect.*).

Common situations: Specs migrated from Jasmine or Karma runners (AngularJS-era codebases); helper files shared between Jasmine and Jest suites; assertions copy-pasted from Jasmine documentation; `pending()` used to mark unfinished work.

Related errors

• Enforce `test` and `it` usage conventions
• Use `{preferred_node_name}` instead.
• Suggest using the built-in comparison matchers
• Prefer mock resolved/rejected shorthands for promises.
• Require a message for {matcher_name:?}.

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