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

Ouverte
#2,663 1 commentaire 0 réactions 0 personnes assignées Réclamée par @fengmk2 Voir sur GitHub
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

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.