Description

vm pools isolate test files with a fresh VM context per run request, which means every file re-compiles and re-evaluates its entire module graph — including externalized node_modules and the Vitest runtime itself. Profiling jsdom + vmThreads runs of fixtures with real dependencies (lodash, lodash-es, date-fns, moment, rxjs, zod, react, react-dom/server) showed three costs this PR removes:

1. Re-compilation per context. Compiled code has no per-context state — only its evaluation does. This PR shares it per worker:

   • inlined modules: compiled vm.Script instances are shared across contexts (safe: Vite rewrites dynamic imports to __vite_ssr_dynamic_import__, so no per-context import callback is baked into the script);
   • externalized CJS: per-worker V8 cachedData, produced after the first execution so it carries the compiled module body (the vm.Script itself stays per-context because it embeds the per-context importModuleDynamically closure);
   • externalized ESM: SourceTextModule cachedData, produced before evaluation as V8 requires.

   Entries are keyed by module id and guarded by the exact source text, so invalidated modules replace their entry, and mock: ids never collide with their originals.

2. An idle server during worker startup. On a cold start every vm worker spends the first ~0.5s of its life importing the environment package (jsdom), while the server has nothing to do; the file's transforms only start after that, serially. vm workers now fire a prewarmModuleGraph RPC before environment.setupVM: the server BFS-transforms the file's import graph through the same fetcher as live fetches during that window. Since the prewarmed transforms set __vitestTmp, the worker's fetchWarmModules snapshot then covers the graph even on the first cold run, and its fetches short-circuit to local disk reads. Prewarm failures are ignored — the worker's own fetch reports errors with the proper import context.

3. Re-resolution of every import edge, per context. ExternalModulesExecutor.resolve calls import.meta.resolve for every ESM import edge of every externalized module, and Node re-derives the resolved module's package scope on each uncached call — re-parsing large exports maps along the way (date-fns's package.json is 199KB with 741 export entries). Node's own resolution cache is keyed by (specifier, parentURL), so each worker still pays the full external graph once (~3300 calls ≈ 700ms of a 9-worker profile on the deps fixture, ×9 workers). Two changes:

   • relative specifiers (restricted to a conservative charset — anything URL-special falls back to Node) resolve by plain URL join. This is exactly what import.meta.resolve returns for them: relative ESM specifiers never consult package.json, and Node's resolver doesn't check existence either — the executor already recreates ERR_MODULE_NOT_FOUND itself;
   • bare specifiers get a worker-wide resolution cache in front of import.meta.resolve (behind the custom vite/mock resolvers, which are unaffected), and module type/existence detection is memoized per worker. Both follow the same worker-lifetime staleness invariants as the existing fileMap/packageCache.

Isolation semantics are unchanged: evaluation still happens once per context, verified by an e2e test that fails if module state leaks through the shared scripts.

Benchmarks (jsdom, vmThreads, isolate: true, fs module cache on; cold = all caches wiped before every rep, warm = populated caches; median of 3 interleaved reps in a single window, M4/Node 24.13, whole-process wall clock; trivial assertions):

vmForks tracks vmThreads (1022-module fixture: 6528ms → 5296ms cold, −19% against the resolution change alone). The split matches the mechanisms: fixtures with externalized dependencies win from the resolution fast path and compile reuse (the costs scale with the external graph), while the no-deps fixture only collects the transform/jsdom-import overlap.

Transform time reporting

The prewarm broke the reported transform time, and investigating that exposed that the stat was already unreliable: it summed each fetch's wall time, but concurrent fetches (parallel workers, and now the prewarm) all wait on the same deduplicated in-flight transforms, so the sum counts the same work many times. Measured on the deps fixture (cold vmThreads run, ~2.5s wall; serial --maxWorkers=1 reference: 356ms of real transform work):

transformTime is now the union of in-flight transform intervals, measured inside the fetcher around the actual transform (fetchAndProcess) — cache hits and fs-cache reads don't tick the clock. It has a crisp meaning ("wall time during which the server was transforming"), is bounded by the run's duration, and behaves identically with and without the prewarm. Warm runs with a populated fsModuleCache now truthfully report ~0 transform time. Per-module durations (metadata.duration, used by the UI module graph) are still recorded from direct worker fetches only — the prewarm's per-module walls would measure BFS queue position rather than the module's own cost.