fix(core): support Jest global mock aliases

[Gobd]

Motivation

Rstest's Jest-compatible utilities can be exposed as jest from a setup file, but module APIs such as jest.mock() currently miss Rstest's compile-time transform and fail at runtime. This makes quick Jest migration trials require broad source edits.

Changes

Translate the exact build-managed Jest module API names to their Rstest equivalents in both Node and Browser mode while preserving existing user SWC globals. Add Node and browser E2E coverage and document the temporary setup-file alias in both migration guides.

The SWC member-global transform is name-based, so a locally shadowed jest.mock() is also rewritten. Rspack's native Rstest parser can distinguish unresolved globals, but currently recognizes only rs and rstest; this tradeoff is called out for review rather than hidden.

Verified with the focused unit test, Node setup fixture, headless browser mock fixture, full package build, type-aware lint, Knip, Prettier, cspell, and heading-case.

[9aoy]

I don’t think this should be part of core’s default pipeline. An opt-in Jest migration plugin would be a better fit.

A config adapter could also be a useful entry point for migration support, along the lines of import { withJestCompat } from '@rstest/adapter-jest'. We should be careful with the naming and scope, though, since we can’t promise automatic Jest config conversion.

import { defineConfig } from '@rstest/core';
import { withJestCompat } from '@rstest/adapter-jest';

export default defineConfig({
  extends: withJestCompat({
    globalsCompat: true,
  }),
});

@fi3ework What do you think?

[fi3ework]

I don’t think this should be part of core’s default pipeline. An opt-in Jest migration plugin would be a better fit.

A config adapter could also be a useful entry point for migration support, along the lines of import { withJestCompat } from '@rstest/adapter-jest'. We should be careful with the naming and scope, though, since we can’t promise automatic Jest config conversion.

import { defineConfig } from '@rstest/core';
import { withJestCompat } from '@rstest/adapter-jest';

export default defineConfig({
  extends: withJestCompat({
    globalsCompat: true,
  }),
});

@fi3ework What do you think?

I believe that with coding agents, large-scale source code editing is simple (especially for most mechanical migrations). While adding this compatibility code to the @rstest/core source might seem beneficial, it would, on one hand, leave behind maintenance costs, and on the other, make it difficult for us to remove this configuration option in the future.

If the goal is to avoid large-scale source code reviews caused by migrations, I think you could abstract this behavior into a skill for internal use. However, I do not currently see a need to support this config, especially given the existence of numerous workarounds.

@rstest/adapter-jest might break the semantics of other current adapters, as the goal of the other adapters is not a testing framework. I think perhaps a dedicated skill would be enough。In particular, this is a temporary state, and I am not inclined to provide code that will incur future migration costs for a temporary transition state.

[Gobd]

The config adaptor would be awesome if it can work, it's just annoying that I can do jest = rs for a quick test, but then I need to change all mocks to get it actually working. I incorrectly assumed with full jest compatibility I could set that 1 thing and be 95% done then slowly change everything later.