chore(deps-dev): upgrade vitest and its coverage provider to 5 - #8306
Merged
Merged
Conversation
Dependabot proposed vitest 5 alone in LibreSign#8295 and the install failed, because @vitest/coverage-v8 pins the vitest version it supports. The two packages have to move together. Grouping them in the Dependabot configuration keeps future updates in a single pull request, so the pair cannot drift apart again. Vitest 5 reports a pending dynamic import as an unhandled rejection when the module runner closes. The router test asserted that the lazy route loader returns a thenable but never awaited it, so the import outlived the test. Awaiting it keeps what the test checks and also proves the component actually loads. Ref LibreSign#8299 Assisted-by: Claude Code:claude-opus-5 Signed-off-by: André Maia <andrefnkmm@gmail.com>
|
Codecov Report✅ All modified and coverable lines are covered by tests. 🚀 New features to boost your workflow:
|
vitormattos
approved these changes
Sep 9, 2026
Member
|
/backport to stable35 |
3 tasks
5 tasks
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
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.
Resolves: #8299
📝 Summary
Moves
vitestand@vitest/coverage-v8to 5.0.0 together and groups them in the Dependabot configuration.@vitest/coverage-v8declares an exact peer on thevitestversion it supports, so raising one alone cannot install. That is what happened in #8295, where the failure occurred during dependency installation, before the frontend checks could run.The lock file was regenerated with a plain
npm install, without--forceand without--legacy-peer-deps. It gets smaller: 66 packages added, 189 removed, 126 changed.The Dependabot group keeps the pair from drifting apart again:
The one migration change
Vitest 5 surfaces a pending dynamic import as an unhandled rejection when the module runner closes, and
npm testexited 1 with:The cause is in the test, not in Vitest.
dynamic component returns thenablecalls the lazy route loader and asserts the returned value has athen, but never awaits it, so the import was still resolving after the test finished and outlived the module runner. Vitest 4 swallowed it.The fix awaits the promise the test already created. It keeps what the test was checking and additionally proves the component really loads, rather than weakening the assertion:
No other test or configuration needed changes. In particular, the two behavioral changes most likely to bite were checked and do not apply here: there are no unawaited
resolves/rejectsassertions anywhere insrc/, and no mock behaviour is configured inbeforeAll, soclearMocksflipping totrueby default changes nothing in this suite.🧪 How to test
npm ci npm test npm run test:coverage npm run ts:check npm run lint npm run stylelint npm run buildEverything below was run locally on Node 24.18.0 / npm 11.16.0:
npm ciERESOLVE, no peer conflictnpm testnpm run test:coveragenpm run ts:checknpm run lintnpm run stylelintnpm run buildTest counts are identical to
main: 248 files and 3118 tests before and after.One thing worth reporting
On the first coverage run,
RequestSignatureTab.spec.ts > uses effective policy when file flow is nonefailed once withexpected 'parallel' to be 'ordered_numeric'. It did not reproduce in 16 further coverage runs on this branch, and the file passes in isolation. That test shares a Pinia store across cases and awaits a single$nextTick, so it is order and timing sensitive independently of the Vitest version; five baseline coverage runs onmainwith Vitest 4 showed no failure but also were not enough to rule it out there.I left it alone, since the issue asks not to modify tests preemptively and this is not a reproducible incompatibility. Flagging it in case it shows up in CI, and happy to open a separate issue for it if you prefer.
✅ Checklist
vitestupdated to 5.x.@vitest/coverage-v8updated to the matching 5.x version.package-lock.jsonregenerated normally, without--forceor--legacy-peer-deps.npm cicompletes without peer dependency errors.🤖 AI (if applicable)