test(vitest): run pool workers with the WASM runtime flags (#1779)

[danusha2345]

What

Fixes #1779. A vitest pool worker was the one launch path that never received --liftoff-only: the bundled launcher, the CLI's self re-exec and refresh-launcher all pass it, the test process did not. So the suite compiled tree-sitter grammars on the turboshaft tier, and once enough parses had warmed a grammar function up, its background tier-up job exhausted a compiler Zone and killed the worker — Fatal process out of memory: Zone, which vitest 2.1.9 reports only as Worker exited unexpectedly, with the rest of the file's tests silently unrun.

The change is the one @bompus proposed in the issue: vitest.config.mts passes WASM_RUNTIME_FLAGS (the same single source the CLI uses) through poolOptions.forks.execArgv. V8 flags are process-global, so the parse worker threads a test spawns are covered too. The ui workspace project does not extend the base and runs no wasm, so it is left alone.

The decisive experiment the issue asked for

Linux x64, Node 24.15.0, __tests__/extraction.test.ts on current main (51116a2, 655 tests). This machine reproduces the crash on demand, always at the same test (the 640th, a large designated-initializer macro call keeps later functions top-level), so the arms are directly comparable:

arm	runs	outcome	wall
no flag (main as is)	4	3 died with Worker exited unexpectedly at 639/655, 1 passed	34–41s
--no-wasm-loop-unrolling	1	died at 639	—
--no-wasm-dynamic-tiering	1	died at 639	—
--no-opt / regexp interpreter / --no-sparkplug --no-maglev	1 each	died at 639 (rules out the JS compilers and irregexp)	—
poolOptions.forks.execArgv: ['--liftoff-only']	2	655/655 both	19–24s

Symbolized native stack of the abort (nm against the node binary): Zone::Expand ← turboshaft::SnapshotTable ← LoopUnrollingPhase::Run ← Pipeline::GenerateWasmCode ← wasm::WasmCompilationUnit::ExecuteCompilation ← BackgroundCompileJob::Run. That is the turboshaft wasm tier-up job, the same mechanism wasm-runtime-flags.ts documents for #293/#298 — and, as that file predicts, only disabling the optimizing tier outright prevents it.

On the cost: here the flag made the file faster, not slower — the baseline arms spend their extra seconds inside the tier-up jobs that eventually die. A full-suite timing on other hardware may differ (the issue measured +25% on Node 26); on this Linux box the extraction file went 34–41s → 19–24s.

__tests__/wasm-runtime-flags.test.ts still passes (it asserts the flag is accepted by the running node).

🤖 Generated with Claude Code

[danusha2345]

Note for whoever lands the Vitest 4 bump (#1667): Vitest 4 drops poolOptions, so this line becomes test.execArgv: [...WASM_RUNTIME_FLAGS] there — verified in #1667 with a probe of the fork's process.execArgv. On main (Vitest 2.1.9) poolOptions.forks.execArgv is the form that reaches the worker.

[bompus]

Verified the delivery path: WASM_RUNTIME_FLAGS is the single source of truth (['--liftoff-only']), V8 flags are process-global so poolOptions.forks.execArgv on the forks pool is the right injection point, and the engine workspace project extends this base config so every tree-sitter suite is covered. The module import adds no side effects at config load (only function definitions). The measured numbers on #1779 (3/4 no-flag deaths at the same test vs 2/2 clean and faster with the flag) justify the change. The Vitest 4 migration note (test.execArgv) is already recorded for #1667.

[colbymchenry]

Thanks @danusha2345! Your commits here were carried into #2046 (authorship preserved), with a few follow-up changes from review, and that is now merged. Closing this one in favour of it. It will be in the next release.