Vite+ 1.0 用一个 vp 收掉 Vite、Vitest、lint 和 Node 版本：升级只改一处，代价是也锁成一套
Vite+ 1.0 于 2026-09-28 发布，出自 VoidZero，MIT 许可，1.0 之后周下载约 200 万。核心做法是把前端项目里散落的一堆工具合并成一个依赖、一个 CLI、一份配置：一个 vite-plus 依赖替代 eslint、prettier、vitest、tsup、turbo 这类包；一个 vp 命令加一份 vite.config.ts，管理 Node.js 运行时、包管理器、dev server、lint/format、测试、构建和任务。
- 项目地址：https://vite.plus
- Vite 官网：https://vite.dev
- 中文站（含月度回顾翻译）：https://vitejs.cn
命令
vp check— 用 Oxfmt 和 Oxlint 一次跑完格式化、lint 和类型检查vp test— 跑 Vitestvp dev/vp build— 跑基于 Rolldown 的 Vite 8vp env— 管理 Node.js 版本vp migrate— 把已有项目迁过来vp toolchain— 打印当前实际使用的工具链版本vp run— 带缓存的任务运行器vp hooks— git hooks；另有vp env doctor做环境检查
工具链版本
vp toolchain 的输出：Vite 8.3.5、Rolldown 1.2.15、Vitest 5.0.5、Oxlint 1.89.0、Oxfmt 0.74.0、tsdown 0.23.1。这些版本全部由单个 vite-plus 包 pin 住。
这带来一个明确的取舍。好处是依赖树只有一层：升级时改一个版本号，拿到的是一组互相测过的组合，不用再处理 vitest 要 5.x 而某个插件只支持 4.x 这类版本冲突。代价是全家桶锁定：Vite、Vitest、Oxlint 的版本由 vite-plus 决定，你没法单独把 vitest 提前到某个小版本，也没法把 oxlint 换回 eslint；如果项目对某个工具有硬性版本要求，只能等上游发版。判断标准大概是——项目愿意跟着 Vite+ 的节奏走，收益明显；项目需要精细控制单个工具版本，这套方案会碍事。
安装与迁移
curl -fsSL https://vite.plus | bash
装完先跑 vp migrate。迁移前先执行一次看迁移计划，确认它会改动哪些配置和依赖，再决定是否落地。生产项目建议先读迁移指南再动手，不要直接在主干上跑。
框架无关，Laravel 已随附
VoidZero 2026 年 9 月的月度回顾（vitejs.cn 上有翻译）提到，Vite+ 是框架无关的，项目甚至不需要使用 Vite。7 月 beta 以来新增了 GitLab CI/CD 支持、tsup 迁移、Homebrew 与 Docker 安装方式、git hooks。目前的使用方包括 Dify、vinext、Tiptap，所有 Laravel starter kit 都已随附 Vite+。
官方给出的收益有三点：维护面变小（升一个版本，组合是测过的）；命令统一（vp dev/check/test/build 在不同仓库里行为一致，对同事和对 coding agent 都一样）；反馈更快（Oxlint、Oxfmt、Rolldown 都是 Rust 实现，加上 vp run 的任务缓存）。
Vite 8.3 里的相关改动
同一次回顾里还提到：Vite 的 bundled dev mode 在开发时直接跑生产打包器，用来压低大型应用的 dev server 开销，目前已经跑通整个 Vite playground 测试集，此前失败的测试约 74% 现在通过。HMR 边界改在浏览器里计算，patch 更小，未变更的重建不发更新，懒加载路由在开发时加载更快，import() 不再在真实模块之前请求 proxy chunk，按路由算请求数减半。另外 Vite 8.3 修了一个问题：当项目文件夹名里包含 node_modules 时，不再把自己的源码文件当成依赖处理。