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
- Langage dominant
- Rust
- Étoiles
- 5.8k
- Forks
- 262
- Merge moyen
- 23 h 18 min
- PR mergées (30 j)
- 139
Description
## 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.
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
Commencez par inspecter les peerDependencies du package vite-plus et les versions publiées référencées dans l’issue, puis comparez-les avec @vitest/browser-playwright@5.0.0 et @vitest/browser-webdriverio. Consultez #2531 pour comprendre la raison des pins exacts. Le travail est considéré comme terminé lorsqu’un chemin de release documenté et compatible pour Vitest 5 et les mises à jour de patch des providers est défini, et que les vérifications pertinentes des packages passent.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- javascript, playwright
- Domaine
- testing, tooling
- Type d'issue
- Fonctionnalité
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- Active
- Clarté
- Plutôt claire
- Accessibilité débutants
- 45/100