voidzero-dev / voidzero-dev/vite-plus
vite-plus peers @vitest/browser-playwright at an exact 4.x, so browser-mode projects cannot adopt Vitest 5
- Lingua principale
- Rust
- Stelle
- 5.8k
- Fork
- 261
- Merge medio
- 1g 34m
- PR unite (30g)
- 135
Descrizione
## 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@ 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.
Guida per i contributori
Apri la guida per i contributori
Direzione di ricerca
Start by inspecting the vite-plus package peerDependencies and the published versions referenced in the issue, then compare them with @vitest/browser-playwright@5.0.0 and @vitest/browser-webdriverio. Review #2531 for the reason behind the exact pins. Done means a documented, compatible release path for Vitest 5 and provider patch updates, with the relevant package checks passing.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- javascript, playwright
- Ambito
- testing, tooling
- Tipo di issue
- Funzionalità
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Stato di attività
- Attiva
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 45/100