[Bug]: rs.mock() does not prevent evaluation of an externalized dependency (real module still runs)

[fi3ework]

Version

System:
    OS: macOS 15.0.1
    CPU: (14) arm64 Apple M3 Max
  Binaries:
    Node: v25.9.0
  npmPackages:
    @rstest/core: 0.10.6
    @rstest/coverage-v8: 0.10.6

Details

When a dependency is externalized — the default for testEnvironment: 'node' (i.e. output.bundleDependencies left unset) — rs.mock() for that dependency does not prevent the real module from being evaluated. The mock value is eventually applied to the importer's binding, but the real module is still loaded and executed first. If the real module has import-time side effects that throw, the test run crashes during that evaluation — before the mock takes effect.

This lives in the same area as #1454 (a module escaping the mock), but the symptom is different. For a harmless externalized module the mock actually does apply — yet the real module is still evaluated. It only surfaces as a failure when the real module throws (or has other observable side effects) at import time.

It bit us migrating a suite from Vitest: a test that mocks electron-updater crashed with Cannot read properties of undefined (reading 'getVersion'), because the real electron-updater was still evaluated and its init runs require('electron').app.getVersion() — outside the Electron runtime require('electron') is a path string, so app is undefined. Under Vitest the mock fully replaces the module and the real code never runs. Bundling the module instead of externalizing it (output.bundleDependencies: true) makes the mock fully replace it under Rstest as well.

Minimal reproduction (no external repo — 3 files)

A node_modules package that throws at evaluation time, node_modules/boom-on-eval/:

package.json

{ "name": "boom-on-eval", "version": "1.0.0", "main": "index.js" }

index.js

// side effect at module-evaluation time
throw new Error('REAL MODULE WAS EVALUATED');
module.exports = { real: true };

index.test.ts

import { expect, it, rs } from '@rstest/core';
import mod from 'boom-on-eval';

rs.mock('boom-on-eval', () => ({ default: { mocked: true } }));

it('mock should prevent the real (throwing) module from being evaluated', () => {
  expect((mod as any).mocked).toBe(true);
});

rstest.config.ts

import { defineConfig } from '@rstest/core';

export default defineConfig({ testEnvironment: 'node', include: ['*.test.ts'] });

Reproduce Steps

1. rstest run → ❌ the suite fails to load with Error: REAL MODULE WAS EVALUATED — the real, mocked module was evaluated.
2. Change the config to output: { bundleDependencies: true } and re-run → ✅ passes; the real module is never evaluated and mod.mocked === true.

Additional observation: if index.js is harmless (e.g. just module.exports = { real: true }, no throw), step 1 passes with mod.mocked === true — i.e. the mock value is applied even when externalized. The problem is specifically that the real module is still evaluated.

Expected

With rs.mock('boom-on-eval') registered, the real boom-on-eval module should not be evaluated at all (as in Vitest), whether it is externalized or bundled.

Actual

The externalized real module is evaluated despite the mock; its import-time throw crashes the run.

---

Update — still reproduces on @rstest/core 0.11.0, plus a second (related) symptom

Re-verified while upgrading Midscene's own test suite from 0.10.6 to 0.11.0: the original symptom above (externalized mocked module still evaluated → electron-updater init crash) still reproduces, and output: { bundleDependencies: true } is still the workaround.

While migrating we hit a second, distinct symptom rooted in the same externalization behavior, which the repro above does not cover:

The mock does not propagate into an externalized package's internal imports. When you rs.mock('A'), but a different externalized package B imports A internally, B resolves the real A — the mock never reaches B. Unlike the first symptom (where the mock value still applies to the test file's binding and only the real module's side effects leak), here the mock does not apply to B's binding at all, so a spy on A gets 0 calls.

Minimal reproduction (no external repo — 4 files)

node_modules/env-singleton/package.json

{ "name": "env-singleton", "version": "1.0.0", "type": "module", "main": "index.js" }

node_modules/env-singleton/index.js

export const readFlag = () => 'REAL';

node_modules/consumer-pkg/package.json — a separate externalized package that imports the mocked one

{ "name": "consumer-pkg", "version": "1.0.0", "type": "module", "main": "index.js" }

node_modules/consumer-pkg/index.js

import { readFlag } from 'env-singleton';
export const useFlag = () => readFlag();

index.test.ts

import { expect, it, rs } from '@rstest/core';
import { useFlag } from 'consumer-pkg';

rs.mock('env-singleton', () => ({ readFlag: () => 'MOCKED' }));

it('mock of a dep should apply inside an externalized package that imports it', () => {
  expect(useFlag()).toBe('MOCKED'); // ❌ receives 'REAL'
});

rstest.config.ts

import { defineConfig } from '@rstest/core';

export default defineConfig({ testEnvironment: 'node', include: ['*.test.ts'] });

Expected

useFlag() returns 'MOCKED' — the rs.mock('env-singleton') should apply to consumer-pkg's internal import { readFlag } from 'env-singleton' (Vitest applies it). Setting output: { bundleDependencies: true } makes it pass under Rstest, same as the first symptom.

Actual

useFlag() returns 'REAL' — the externalized consumer-pkg resolved the real env-singleton, so the mock (and any spy on it) never took effect.

Real-world hit in Midscene: a test mocks @midscene/shared/env, but processCacheConfig (in the externalized workspace pkg @midscene/core/utils) reads the env singleton from the real @midscene/shared/env, so the spy on getEnvConfigInBoolean gets 0 calls. Same root cause (externalization), different surface from the electron-updater case — worth either widening this issue's scope or splitting it out.

[9aoy]

The root cause is a timing mismatch between the external output shape and the mock runtime.

In testEnvironment: 'node', dependencies are externalized by default. For an ESM import, Rspack may emit something like:

import * as external from "/path/to/node_modules/pkg/index.js";

__webpack_modules__ = {
  "pkg"(module) {
    module.exports = external;
  },
};

The real module is evaluated by the native ESM loader before the bundle body runs. rs.mock() is hoisted, but it still installs the mock at bundle runtime by replacing __webpack_modules__[id], so import-time side effects from the real external module can happen before the mock is applied.

Possible workarounds / directions:

1. Bundle the mocked dependency

export default defineConfig({
  output: {
    bundleDependencies: ['electron-updater'],
    // or temporarily: bundleDependencies: true
  },
});

This puts the dependency into the Rspack module graph, so rs.mock() can replace the real factory before it runs.

2. Emit mocked externals as CJS externals
   For mocked externals, emit commonjs / node-commonjs instead of native static ESM imports, so loading is delayed until __webpack_require__('pkg'). Rstest’s current Node range supports require(esm), but this still has semantic caveats around TLA, interop, and dual-package exports conditions, so it should be targeted to mocked externals rather than applied globally.

3. Longer term: import defer
   If Node.js and Rspack support import defer in the future, mocked externals could keep static loading while deferring evaluation. That would better match ESM semantics, but it is not usable as a current fix yet.

[fi3ework]

Tested against #1485 — it does not fix this issue

I built @rstest/core from #1485 (fix/mock-nonliteral-dynamic-import) with the rspack canary it pins (@rspack-canary/core@2.1.3-canary-7caa6eff), on Node v25.9 (well above the module.registerHooks floor of 22.15/23.5), and compared it against published 0.11.0 on a matrix of minimal cases.

Results (❌ fail, ✅ pass)

#	Scenario	Module	Import	0.11.0	#1485 + canary
1	mock target statically imported by the test, throws at eval (this issue's original repro)	CJS	static	❌ real evaluated	❌ real evaluated
2	mock must reach a statically-imported externalized pkg's internal import (second symptom)	ESM	static	❌ REAL	❌ REAL
3	#1454 control — non-literal import() of a mocked module	ESM	dynamic	❌	✅ MOCKED
4	mock must reach a dynamically-imported externalized pkg's internal import	ESM	dynamic	❌	✅ MOCKED
5	non-literal import() of a throwing module	CJS	dynamic	❌	❌ real evaluated
6 / 7	throwing module, dynamic / static	ESM	both	❌	❌ real evaluated
8	dynamic import(); assert the real module's side effect never ran	ESM	dynamic	—	importer gets MOCKED ✅ but the real module still evaluated (__SFX_REAL_RAN === 1) ❌

Why #1485 doesn't address this issue

#1485's module.registerHooks native bridge substitutes the value the importer receives with the mock (so cases 3/4/8 see MOCKED), but:

1. It does not prevent the real externalized module from being evaluated. Case 8 is decisive: the importer gets the mock and the real module's side effect still ran; cases 5/6/7 still throw from the real module at eval time. This issue's core ask — don't evaluate the real module (the electron-updater crash happens during that evaluation) — is untouched.
2. It only engages for runtime dynamic import(). The bridge is installed lazily on the first rs.mock(), which runs in the bundle runtime — but a top-level static externalized import is evaluated by the native ESM loader before the bundle body (including the hoisted mock registration) runs, so the hook isn't installed yet (cases 1/2/7 miss). This issue's repro, and every real hit we have, use top-level static imports.
3. CJS on the native path is unmocked by design (case 5) — per feat(core)!: apply rs.mock to non-literal dynamic import() #1485's own note, "require() on the native path stays unmocked".

So #1485 is correctly scoped to #1454 (applying rs.mock to non-literal dynamic import()); it incidentally improves mock-value propagation into a dynamically-loaded externalized package, but it does not fix #1456's two core symptoms (real module still evaluated; static-import case). This issue still needs a resolve/load-time interception that (a) covers top-level static imports and (b) actually prevents the real externalized module from being evaluated.