Summary
Every published vite-plus peer-depends on @vitest/browser-playwright (and @vitest/browser-webdriverio) at an exact 4.x patch. @vitest/browser-playwright@5.0.0 in turn requires vitest@5.0.0. So a project that uses Vitest browser mode through Vite+ cannot adopt Vitest 5 until a vite-plus release peers a 5.x provider.
Is Vitest 5 support planned, and is there an issue to follow?
The pins
$ npm view vite-plus@<v> peerDependencies
vite-plus@0.2.8: { "@vitest/browser-playwright": "4.1.10", "@vitest/browser-webdriverio": "4.1.10" }
vite-plus@0.2.9: { "@vitest/browser-playwright": "4.1.10", "@vitest/browser-webdriverio": "4.1.10" }
vite-plus@0.3.0: { "@vitest/browser-playwright": "4.1.11", "@vitest/browser-webdriverio": "4.1.11" }
vite-plus@0.3.1: { "@vitest/browser-playwright": "4.1.11", "@vitest/browser-webdriverio": "4.1.11" }
The other side:
$ npm view @vitest/browser-playwright@5.0.0 peerDependencies
{ vitest: '5.0.0', playwright: '*' }
$ npm view vitest version
5.0.0
$ npm view vite-plus dist-tags
{ test: '0.0.2-…', alpha: '0.1.21-alpha.7', latest: '0.3.1' }
latest is 0.3.1, so there is currently no release — stable or alpha — whose provider peer admits Vitest 5.
Why it matters beyond the major
Because the peer is an exact version rather than a range, even a patch bump of the provider needs a matching vite-plus release. That is the mechanism behind #2531 (0.2.9 pinning vitest@4.1.10 while the provider resolved to 4.1.11) — the 0.3.x line moved the pin from 4.1.10 to 4.1.11 and cleared that particular mismatch, but the exact-pin shape that produced it is unchanged.
Would a caret range (^4.1.11) be viable for the provider peers, so provider patches don't require a vite-plus release? I appreciate there may be a bundled-copy/singleton reason for the exact pin — if so it would be useful to have that written down, since from the outside it reads as something that could be loosened.
Context
A Vue 3 + Vitest browser-mode project on pnpm, just migrated from standalone Vitest to vp test on 0.3.1. The migration itself went cleanly; Vitest 5 was the one thing we had hoped it would unblock, and it is held on this pin alone.
Summary
Every published
vite-pluspeer-depends on@vitest/browser-playwright(and@vitest/browser-webdriverio) at an exact 4.x patch.@vitest/browser-playwright@5.0.0in turn requiresvitest@5.0.0. So a project that uses Vitest browser mode through Vite+ cannot adopt Vitest 5 until avite-plusrelease peers a 5.x provider.Is Vitest 5 support planned, and is there an issue to follow?
The pins
The other side:
latestis 0.3.1, so there is currently no release — stable or alpha — whose provider peer admits Vitest 5.Why it matters beyond the major
Because the peer is an exact version rather than a range, even a patch bump of the provider needs a matching
vite-plusrelease. That is the mechanism behind #2531 (0.2.9 pinningvitest@4.1.10while the provider resolved to 4.1.11) — the 0.3.x line moved the pin from4.1.10to4.1.11and cleared that particular mismatch, but the exact-pin shape that produced it is unchanged.Would a caret range (
^4.1.11) be viable for the provider peers, so provider patches don't require avite-plusrelease? I appreciate there may be a bundled-copy/singleton reason for the exact pin — if so it would be useful to have that written down, since from the outside it reads as something that could be loosened.Context
A Vue 3 + Vitest browser-mode project on pnpm, just migrated from standalone Vitest to
vp teston 0.3.1. The migration itself went cleanly; Vitest 5 was the one thing we had hoped it would unblock, and it is held on this pin alone.