Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

vite-plus peers @vitest/browser-playwright at an exact 4.x, so browser-mode projects cannot adopt Vitest 5

クローズ
#2,663 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@fengmk2 がすでに取り組んでいます。

2026年8月24日 から。

  • #2551 @fengmk2 による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
javascript, playwright
領域
testing, tooling

調査の方向性

まず vite-plus パッケージの peerDependencies と issue で参照されている公開済みバージョンを調べ、@vitest/[email protected] および @vitest/browser-webdriverio と比較します。正確な pin の理由については #2531 を確認してください。Vitest 5 と provider の patch 更新に対応した、互換性のあるリリース手順が文書化され、関連するパッケージチェックが通れば完了です。

索引モデルが issue の本文から書いたものです。

説明

Summary

Every published vite-plus peer-depends on @vitest/browser-playwright (and @vitest/browser-webdriverio) at an exact 4.x patch. @vitest/[email protected] in turn requires [email protected]. 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

[email protected]: { "@vitest/browser-playwright": "4.1.10", "@vitest/browser-webdriverio": "4.1.10" }
[email protected]: { "@vitest/browser-playwright": "4.1.10", "@vitest/browser-webdriverio": "4.1.10" }
[email protected]: { "@vitest/browser-playwright": "4.1.11", "@vitest/browser-webdriverio": "4.1.11" }
[email protected]: { "@vitest/browser-playwright": "4.1.11", "@vitest/browser-webdriverio": "4.1.11" }

The other side:

$ npm view @vitest/[email protected] 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 [email protected] 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.

主要言語
Rust
スター
5.8k
フォーク
267
平均マージ
21時間 10分
マージ済み PR(30日)
148

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

voidzero-dev/vite-plus のほかの issue

voidzero-dev/vite-plus の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。