vite-plus peers @vitest/browser-playwright at an exact 4.x, so browser-mode projects cannot adopt Vitest 5
维护者通常 1 天内回复
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 45/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- javascript, playwright
调研方向
首先检查 vite-plus 包的 peerDependencies 以及 issue 中引用的已发布版本，然后将它们与 @vitest/[email protected] 和 @vitest/browser-webdriverio 进行比较。查看 #2531，了解使用精确 pin 的原因。当 Vitest 5 和 provider 的补丁更新都有一条已记录且兼容的发布路径，并且相关的包检查通过时，即视为完成。
由索引模型根据 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 小时 16 分钟
- 30 天内合并 PR
- 147
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
voidzero-dev/vite-plus 的其他 Issue
-
pending triage
难度 2/5 1-3 小时 新手友好度 75/100
voidzero-dev/vite-plus#2801 · 1 个 reaction ·
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 62/100
voidzero-dev/vite-plus#2097 · 10 条评论 · 2 个 reaction ·
维护者通常 1 天内回复
-
vp check --no-lint still reports type-aware lint rules and ignores their disable comments可能已有人在做 @camc314 今天认领。 未关闭
voidzero-dev/vite-plus#2830 · 已指派 1 人 ·
维护者通常 1 天内回复
-
vp run: task output forwarding aborts with EAGAIN when stdout turns non-blocking mid-run (follow-up to #2165)可能已有人在做 @naokihaba 于 1 天前认领。 未关闭bug
voidzero-dev/vite-plus#2824 · 3 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
pending triage
难度 4/5 3-5 天 新手友好度 55/100
voidzero-dev/vite-plus#2816 ·
维护者通常 1 天内回复
查看 voidzero-dev/vite-plus 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 92/100
bytecodealliance/wasmtime#14433 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
-
bug
难度 2/5 1-3 小时 新手友好度 76/100
-
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复