Summary
In the root package.json, vitest and @vitest/coverage-v8 have drifted apart: @vitest/coverage-v8 tracks the latest patch (currently ^4.1.10) while vitest has been stuck at ^4.1.2. Digging through history, they last moved together in #5140 (both ^4.1.2) and split at #5171, which bumped @vitest/coverage-v8 to ^4.1.3 but left vitest at ^4.1.2. From then on every vitest-group bump widened the gap.
The cause is the caret ranges combined with dependabot's versioning-strategy: increase. @vitest/coverage-v8 declares vitest as an exact peer dependency, so bumping coverage-v8 drags vitest's resolved version forward in the lockfile without any manifest change. Since vitest's caret range already permits that version, dependabot never rewrites its requirement, whereas coverage-v8's floor gets rewritten on every release. The two therefore stay in lockstep in the lockfile but drift in the manifest, which reads like a broken/partial update in dependabot PRs (e.g. #5580).
Why is this needed?
vitest and @vitest/coverage-v8 are released in lockstep upstream and must match at runtime (coverage-v8 pins vitest as an exact peer). Keeping their manifest ranges aligned removes the recurring confusion in dependabot PRs where the body reports two updates but the manifest diff shows only one, and makes the coupling obvious at a glance.
Which area does this relate to?
Solution
Pin both vitest and @vitest/coverage-v8 to the same exact version (drop the carets), e.g. 4.1.10. With exact pins, a new release no longer satisfies the existing requirement, so dependabot's increase strategy is forced to rewrite both requirements together on every bump — guaranteeing lockstep in the manifest, not just the lockfile. Simply re-tightening the caret floors is not durable: the ranges were already identical (^4.1.2) when they diverged at #5171, so equal caret floors demonstrably drift again. Dependabot continues to update exact-pinned dependencies normally (the vitest group still applies).
Acknowledgment
Summary
In the root
package.json,vitestand@vitest/coverage-v8have drifted apart:@vitest/coverage-v8tracks the latest patch (currently^4.1.10) whilevitesthas been stuck at^4.1.2. Digging through history, they last moved together in #5140 (both^4.1.2) and split at #5171, which bumped@vitest/coverage-v8to^4.1.3but leftvitestat^4.1.2. From then on every vitest-group bump widened the gap.The cause is the caret ranges combined with dependabot's
versioning-strategy: increase.@vitest/coverage-v8declaresvitestas an exact peer dependency, so bumping coverage-v8 dragsvitest's resolved version forward in the lockfile without any manifest change. Sincevitest's caret range already permits that version, dependabot never rewrites its requirement, whereas coverage-v8's floor gets rewritten on every release. The two therefore stay in lockstep in the lockfile but drift in the manifest, which reads like a broken/partial update in dependabot PRs (e.g. #5580).Why is this needed?
vitestand@vitest/coverage-v8are released in lockstep upstream and must match at runtime (coverage-v8 pinsvitestas an exact peer). Keeping their manifest ranges aligned removes the recurring confusion in dependabot PRs where the body reports two updates but the manifest diff shows only one, and makes the coupling obvious at a glance.Which area does this relate to?
Solution
Pin both
vitestand@vitest/coverage-v8to the same exact version (drop the carets), e.g.4.1.10. With exact pins, a new release no longer satisfies the existing requirement, so dependabot'sincreasestrategy is forced to rewrite both requirements together on every bump — guaranteeing lockstep in the manifest, not just the lockfile. Simply re-tightening the caret floors is not durable: the ranges were already identical (^4.1.2) when they diverged at #5171, so equal caret floors demonstrably drift again. Dependabot continues to update exact-pinned dependencies normally (thevitestgroup still applies).Acknowledgment