perf(repo): halve vm runner mutation wall time with identical verdicts

[systemfsoftware-maker]

Summary

A stryker run with testRunner: 'vm' now takes about half the wall time, and every mutant verdict is the same as before. The saving comes from idle time: checkers now run in parallel and release their share of concurrency when they finish, and workers start faster (a shared compile cache, and a worker thread booted before the test file that needs it).

Layer 3 of stack #112, on top of #111, which made vm run the real Vitest runner and fixed its verdicts but left it about as slow as testRunner: 'vitest'.

Measurements

Enterprise fixture (4 packages, 319 mutants, TypeScript checker), stryker.vm.config.ts, 5 interleaved pairs of the #111 head against this branch. The host load was 29-55 on 8 cores, so absolute times are noisy; the paired gap is not.

	#111 head	This PR
Wall time (median)	24.94 s	12.64 s
First tested mutant	14.24 s	6.81 s
Verdict differences (12 runs, 319 mutants)	reference	0

A rebuild of the final head measured 10.87 to 11.42 s over 4 runs, again with 0 differences.

What each change bought, each measured against the previous best:

Change	Before	After
Check mutant groups on every checker process at once	20.67 s	17.95 s
Stop the checker processes as soon as checking ends	17.95 s	16.45 s
Share a Node compile cache with every worker	15.79 s	14.87 s
Give the checkers' share of concurrency to test runners after checking	15.64 s	12.76 s
Boot the next isolated worker thread ahead of time	11.98 s	11.24 s

Two other experiments were measured and dropped: one scheduler streaming checked mutants straight into test runs (no gain, because the host is CPU-bound), and grouped type-checking in the TypeScript checker (11 % slower).

Design decisions

• Isolation is unchanged. Each test file still gets a brand-new worker thread. The standby pool only boots that thread while the previous file runs. A spare is handed out only when the project, env and execArgv match what it was booted with, because the thread bakes those in at boot. Vitest sends the config and environment in the start message for each file, after the claim, so a spare booted during the dry run cannot carry stale settings into a mutant run.
• Vitest API risk. The standby pool plugs in through Vitest's poolRunner option and ThreadsPoolWorker, both marked @experimental in Vitest 5.0.1. A Vitest minor could break it; the vm parity differential would catch a verdict change.
• Brief oversubscription. When checking ends, the test-runner pool can grow from testRunners to testRunners + checkers (idle runners retire after 1 minute) while the checker processes are still shutting down in the background. Until they exit, more processes than concurrency can be alive.
• Compile cache location. The CLI calls module.enableCompileCache() and passes the directory to every worker through NODE_COMPILE_CACHE. It uses Node's default directory under the OS temp dir, as TypeScript's own tsc does. NODE_DISABLE_COMPILE_CACHE=1 turns it off, and on Node older than 22.8 the CLI runs without it instead of crashing before the version check.
• Cleanup on failure. A runtime that fails after Vitest starts, such as a refused browser-mode project, now closes its driver. That stops its standby threads and removes the stryker-setup-*.js file it copied into the project.

Validation

pnpm check:ci (format, lint, typecheck, every test suite including the vm parity differential, build) and the changeset gate pass on the head of this branch.

New tests, each shown to fail against the behaviour it pins:

• Standby pool properties: spare reuse only on an identical request with exactly one replacement booted, a boot or post-claim failure rejecting start(), and disposal waiting for every stop.
• Checker properties: results stay in plan order when later groups finish first; checks spread over distinct pool slots without exceeding the pool; a crashed checker slot is replaced; checker contract breaches become mutation-test stage errors; the checkers are released exactly once when checking finishes, fails or is interrupted.
• The browser-mode refusal scenario now also asserts that no setup file is left in the project. On the previous head it found stryker-setup-<uuid>.js left behind.

Not covered by a test: the order in which the worker environment is merged, which is what lets a user's NODE_COMPILE_CACHE or NODE_DISABLE_COMPILE_CACHE win. The node driver that builds it cannot host in-source tests under the repo's lint rules; a smoke run confirmed that 4 test-runner workers, 4 checker workers and their Vitest threads all read the same cache directory.

New concepts

Node's module compile cache. Since Node 22.8, module.enableCompileCache() stores V8 code cache for the CommonJS and ESM modules Node loads in a directory on disk. The next process that loads the same file skips parsing and compiling it. A child process joins the same cache when NODE_COMPILE_CACHE names the directory.

Why here: a mutation run starts dozens of short-lived processes and worker threads that each load the same Vitest, Vite and TypeScript bundles. A thread-reuse scheme would also save that time, but it would weaken per-file isolation. The cache speeds up every fresh start and leaves isolation alone.

Example: packages/stryker-js/src/bin/enable-compile-cache.ts enables it at CLI start, and the node driver adds NODE_COMPILE_CACHE to every worker it spawns.

When not to use it: when coverage depends on V8 source positions (Vitest turns the cache off itself for v8 coverage), or in a library that other code imports, where turning it on would be a side effect on the host process.

Related: #100

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}