Complete the vitest 5 upgrade and port maxForks to maxWorkers #127
No reviewers
Labels
No labels
dependencies
major
security-pin
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
trails-cool/trails!127
Loading…
Reference in a new issue
No description provided.
Delete branch "vitest-5-complete-set"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
#121 merged
@vitest/browserto^5.0.0on its own, leavingmainwith a split version set:@vitest/browser-playwright@4.1.11pins"@vitest/browser": "4.1.11"exactly and peers"vitest": "4.1.11", so pnpm installed two parallel@vitest/browsertrees — the splitrenovate.json5's #38 note exists to prevent.It went green because the v5 copy was unused. The only source import is
@vitest/browser-playwright, which resolved its own v4 copy, so the entire live chain stayed v4 while the 5.0.0 tree sat installed and idle. Green and wrong at once — the mismatch would have surfaced as a failure of #122, the browser-playwright bump, rather than of the change that caused it.The fix
Takes
vitestand@vitest/browser-playwrightto^5.0.0so the whole release train matches. Verified the duplicate tree is gone and the exact peer is satisfied:vitest@vitest/browservitest 5.0.0@vitest/browser-playwright@vitest/browser 5.0.0, peersvitest 5.0.0It also ports #126's worker cap, which vitest 5 broke
vitest 5 removed
poolOptionsand replaced it with a top-level, pool-agnosticmaxWorkers?: number | string. Two PRs that were each correct alone merged into a config that does not typecheck — #126 was written against v4 while #121 was moving to v5.maxWorkers: 2under CI restores the intended bound.The two are not exactly equivalent — the old form capped forks per pool, the new one caps workers per project — but that is the same thing here, because nothing sets a non-default pool.
Verified
pnpm typecheckexit 0 (14 tasks)pnpm lintexit 0CI=1 TURBO_CONCURRENCY=3 pnpm testgreen across 12 tasksSupersedes
#122 can be closed once this lands.
vitest 5 writes failure attachments to `.vitest/attachments/` instead of `.vitest-attachments/`. Both consumers still pointed at the old path, and both failed quietly rather than loudly: find apps/planner/.vitest-attachments -name "*-diff-*.png" -> no matches upload-artifact path: apps/planner/.vitest-attachments/ -> "No files were found with the provided path" So the six genuine screenshot failures on this branch were still red, but the evidence for them was thrown away: no diff comment on the PR and no `visual-snapshots-diff` artifact to download. The step that reads worst in the log — "Post diff comment on PR" — had in fact done its job and exited 0 with nothing to post; the `exitcode '1'` beside it belongs to `test:visual` itself. Also sets `if-no-files-found: ignore` on the upload. That step runs on ANY job failure, including failures that produce no screenshots at all — a typecheck error, or a browser that would not launch — and the default `warn` printed "No files were found" against runs where no files were ever expected. DELETES THE SIX DARWIN BASELINES. They are 912x154 and the linux ones are 483x81, while the canvas under test is declared `width={600} height={100}` and drawn with `drawElevationChart(ctx, 600, 100, ...)`. Neither baseline matched the element: vitest 4 captured a device-pixel-ratio-scaled box, which is why the two platforms disagreed at all. vitest 5 captures the true CSS size, so both platforms now produce 600x100 and the stored darwin files can never match again. Deleted rather than left to fail every local `test:visual`; the first local run writes fresh ones. The linux baselines are regenerated by the "Update visual snapshots" workflow, which is the only place they can legitimately come from. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W9K6hHEZx5aqyWZKHNrxsDThis job was still on `runs-on: playwright` — the runner-label-pinned image — long after ci.yml's visual-tests and e2e jobs moved to an in-repo `container:` declaration. That made it the last place the #38/#66 lockstep bug could bite, and it did, on the first dispatch after the vitest 5 upgrade: browserType.launch: Executable doesn't exist at /ms-playwright/chromium_headless_shell-1234/chrome-headless-shell-linux64/... A nasty shape, because this is the workflow that GENERATES the baselines. When the runner image drifts from the lockfile's playwright, CI fails on a screenshot mismatch AND the only sanctioned way to regenerate the baselines is broken by the same drift — so the documented recovery path does not work precisely when it is needed. Now uses the same `mcr.microsoft.com/playwright:v1.62.1-noble` as the two CI browser jobs, and carries the same "assert the image ships the browsers this playwright needs" check. That check matters more here than anywhere else: this job writes the baselines every other run is compared against, so a silent browser mismatch would bake wrong pixels into the repo rather than merely fail. Also corrects two header comments that still described `runs-on: playwright` as the mechanism. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W9K6hHEZx5aqyWZKHNrxsD838a3dfa10to6d628d7ffa6d628d7ffato4fbebfa70f