oxc-project/oxc · warning

`expect` is shadowed by a callback parameter and cannot be u

Error message

`expect` is shadowed by a callback parameter and cannot be used for assertions.

What it means

This diagnostic comes from the oxlint `prefer-expect-assertions` rule. When the rule tries to resolve which `expect` a test uses (file-level import prefix vs global), it walks the test callback; if a callback parameter is named `expect` (shadowing the global/imported one), the resolver returns None and the rule reports that it cannot reason about assertions. Shadowing also means calls inside that callback do not run the real Jest expect, so `expect.assertions(n)` bookkeeping would be wrong anyway.

Source

Thrown at crates/oxc_linter/src/rules/shared/jest_vitest/prefer_expect_assertions.rs:160

  fetchData((data) => {
    expect(data).toBe('peanut butter');
  });
});
```

Examples of **correct** code with `{ "onlyFunctionsWithExpectInCallback": true }`:
```javascript
test('callback test', () => {
  expect.assertions(1);
  fetchData((data) => {
    expect(data).toBe('peanut butter');
  });
});
```
"#;

fn expect_shadowed_by_parameter(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn(
        "`expect` is shadowed by a callback parameter and cannot be used for assertions.",
    )
    .with_help("Rename the parameter to avoid shadowing the global `expect`.")
    .with_label(span)
}

pub fn has_assertions_takes_no_arguments(span: Span, prefix: &str) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("`{prefix}.hasAssertions` expects no arguments."))
        .with_help(format!("Remove the arguments from `{prefix}.hasAssertions()`."))
        .with_label(span)
}

fn assertions_requires_one_argument(span: Span, prefix: &str) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("`{prefix}.assertions` expects a single argument of type number."))
        .with_help(format!("Pass a single numeric argument to `{prefix}.assertions()`."))
        .with_label(span)
}

View on GitHub (pinned to e1e7af627c)

Solutions

  1. Rename the shadowing parameter (e.g. `expect` → `assert` or `ctx`) at both the declaration and its uses.
  2. If using a framework that injects `expect` as a destructured parameter, disable this rule for those files or configure the rule off, since the injected expect is intentional.
  3. For node:test-style code migrating to Jest, replace the injected parameter with the global/imported `expect`.

Example fix

// before
test('scenario', () => {
  runScenario((payload, expect) => {
    expect(payload).toBe('ok');
  });
});

// after
test('scenario', () => {
  runScenario((payload, assert) => {
    expect(payload).toBe('ok');
  });
});
Defensive patterns

Strategy: validation

Validate before calling

// .oxlintrc.json
{ "rules": { "jest/prefer-expect-assertions": "error" } }

npx oxlint tests/

Prevention

When it happens

Trigger: A test whose callback — or a nested callback passed to the function under test — declares a parameter named `expect`, e.g. `runScenario((...args, expect) => ...)` or `test('x', () => { fn((expect) => {}); })`, causing `resolve_expect` to fail and the rule to emit this diagnostic on the test callee span.

Common situations: Testing libraries whose API passes an assertion object to callbacks (e.g. `test('x', ({ expect }) => ...)` in some frameworks); renaming a callback parameter during refactoring to `expect`; porting tests from frameworks where `expect` is injected (node:test style) into Jest/Vitest.

Related errors


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