test: fileParallelism: false — the option singleThread was pretending to be - #67
Open
unixwhisperer wants to merge 1 commit into
Open
unixwhisperer wants to merge 1 commit into
unixwhisperer wants to merge 1 commit into
Conversation
… to be `singleThread: true` has been sitting in vitest.config.js doing nothing. It is not a vitest 4 option: it was `poolOptions.threads.singleThread` in v1, and `poolOptions` itself is absent from 4.1.11's types — checked, `grep` over node_modules/vitest for `poolOptions` in any .d.ts returns nothing, while `fileParallelism` is there as a top-level key. Vitest ignores unknown config keys silently, so the suite has been running files in PARALLEL the whole time, which is the opposite of what that line was asking for. The run summary showed it plainly: summed test time 1153.99s against a 117.27s wall clock, i.e. ~10 workers. It matters because `isolate: false` is set directly below, so files that share a worker also share module state, and which files share a worker is not deterministic. The suite was green, but green under a scheduling arrangement nobody chose and nobody can reproduce on purpose. MEASURED, same tree, only this config line differing: parallel (before) wall 117.27s tests 1153.99s setup 25.73s serialised (after) wall 136.89s tests 133.92s setup 0.91s So the wall-clock cost of serialising is ~20 seconds, not the 10x the summed figure suggests — the parallel run was mostly contending with itself, re-running setup in every worker and thrashing. Total test work drops 8.6x. 221/221 across 20 files before and after. Discovery is untouched: same file count, same test count, so the green run asserts exactly what it did before. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
unixwhisperer
enabled auto-merge
September 21, 2026 10:13
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You were right about the types, and it's worse than a form error.
grepovernode_modules/vitestforpoolOptionsin any.d.tsin 4.1.11 returns nothing;fileParallelismis there as a top-level key.singleThreadisn't in the types either — and vitest ignores unknown config keys silently, sosingleThread: truehas been sitting invitest.config.jsdoing nothing. The suite has been running files in parallel this whole time, the opposite of what that line was asking for.The run summary said so in plain sight: summed test time 1153.99s against a 117.27s wall clock.
It matters because
isolate: falseis set directly below it. Files sharing a worker share module state, and which files share a worker isn't deterministic. The suite was green — but green under a scheduling arrangement nobody chose and nobody can reproduce on purpose.Measured, same tree, only this config line differing
Serialising costs about 20 seconds of wall clock, not the 10x the summed figure implies. The parallel run was mostly contending with itself — re-running setup in every worker and thrashing. Total test work drops 8.6x.
221/221 across 20 files before and after. Same file count, same test count, so the green run asserts exactly what it did before — no tests quietly dropped out of discovery.
One line of config, one comment block explaining why, no test touched.
🤖 Generated with Claude Code