Vite+ 实战：用 vp 命令统一前端工作流
译注：本文译自 dev.to 系列文章《Vite+ — Chapter 3: Vite+ in Practice》，作者 Othmane Nemli，原文发布于 2026 年 9 月 25 日。该系列上一章介绍了 Vite+ 由哪些工具组成，本章聚焦实际开发体验。原文链接见文末。
在上一章中，我们了解了 Vite+ 的构成。它整合了 Vite、Vitest、Rolldown、tsdown、Oxlint、Oxfmt 和 Vite Task 等工具。但知道这些工具是什么只是一半，更有意思的问题是：用 Vite+ 开发一个真实项目，实际体验是什么样的？
本章将创建一个项目、启动开发服务器、运行检查与测试，最后完成生产构建。
安装 Vite+
Vite+ 提供 vp 命令行接口。官方 beta 版安装方式因操作系统而异。
macOS / Linux：
curl -fsSL https://vite.plus | bashWindows：
irm https://vite.plus/ps1 | iex安装后验证：
vp --version可以把 vp 理解为进入 JavaScript 项目的主入口。你不再需要记住每个环节该用哪个工具，而是统一使用同一套命令行接口。
创建新项目
# 交互模式
vp createVite+ 内置以下模板：
vp vite:monorepo # 创建 monorepo
vp vite:application # 创建应用
vp vite:library # 创建库创建完成后进入项目目录：
cd my-project安装依赖
传统做法是 npm/pnpm/yarn/bun install，Vite+ 提供了自己的入口：
vp installVite+ 能兼容不同的包管理器，并自动检测项目使用的包管理器配置。这背后的理念是：你不必更换底层工具，Vite+ 只是在它们之上提供一致的接口。目标不是"所有人都别用 npm 了"，而是"开发者不必关心工作流中每个环节该由哪条命令负责"。
启动开发服务器
vp dev底层使用的仍是 Vite 开发服务器，你会获得熟悉的 Vite 开发体验，包括修改源码时的快速模块更新。默认项目自带一个计数器组件：
apps/website/src
├── counter.ts
├── main.tsx
└── styles.css编辑 main.tsx，把 "Get started" 改成 "Welcome Vite+" 并保存，浏览器会自动更新，无需手动重新构建整个应用。Vite+ 并不试图取代这套体验，只是为它提供了一致的命令入口。
检查代码
提交代码前，通常需要确认：代码是否已格式化、有无 lint 错误、有无类型错误。传统上可能是三条命令：
npm run format
npm run lint
npm run typecheck使用 Vite+ 可以合并为：
vp check当前 Vite+ 工作流将格式化、lint 和类型检查合并在一起。对小项目来说差别不大，但设想一个拥有 10 名开发者、20 个仓库、多个应用、共享包、CI 流水线和多环境的团队，一条一致的命令价值就大得多。
运行测试
假设有如下测试：
import { describe, expect, it } from 'vitest'
describe('addition', () => {
it('adds two numbers', () => {
expect(1 + 2).toBe(3)
})
})传统上直接运行 vitest，使用 Vite+ 则是：
vp testVite+ 通过 Vitest 运行测试。注意这里的模式：
开发 → vp dev
检查 → vp check
测试 → vp test你不需要记住每条命令背后由哪个工具驱动，只需学习 Vite+ 的工作流。
生产构建与预览
应用准备部署时，运行：
vp build应用通过 Vite 和 Rolldown 完成生产构建。关键区别在于：
vp dev
↓
开发环境
vp build
↓
生产构建开发阶段追求速度和快速反馈，生产阶段追求可部署的优化产物，Vite+ 为两者提供一致的接口。
构建完成后可以本地预览：
vp preview一个简单的工作流因此成型：vp dev 开发 → vp check 检查 → vp test 测试 → vp build 构建 → vp preview 预览。
工作流一览
| 你想做的事 | Vite+ 命令 |
|---|---|
| 创建项目 | vp create |
| 安装依赖 | vp install |
| 启动开发 | vp dev |
| 检查代码 | vp check |
| 运行测试 | vp test |
| 生产构建 | vp build |
| 预览生产版本 | vp preview |
Vite+ 的核心思路不是替换每一个单独的工具，而是为开发工作流创建一个一致的接口。
已有项目怎么办
Vite+ 提供了迁移命令：
vp migrate假设一个已有项目包含 package.json、vite.config.ts、vitest.config.ts、eslint.config.js、prettier.config.js 和 src/，运行 vp migrate 后，Vite+ 可以将部分现有配置纳入其统一设置。当前的迁移流程会展示计划变更的内容，但复杂项目可能仍需手动跟进。官方文档建议在生产项目上使用前先阅读迁移指南。因此迁移不应被理解为"运行一条命令，一切自动改变"，而更像是"Vite+ 帮助现有项目向统一工作流靠拢"。
单一配置文件
Vite+ 项目可以使用 vite.config.ts 作为集中配置点：
import { defineConfig } from 'vite-plus'
export default defineConfig({
plugins: [],
test: {
include: ['src/**/*.test.ts'],
},
lint: {
ignorePatterns: ['dist/**'],
},
fmt: {
semi: true,
singleQuote: true,
},
})同一份配置可以包含工作流不同环节的设置：
vite.config.ts
│
├── Vite
├── Vitest
├── Oxlint
├── Oxfmt
└── Vite Task目标是减少需要理解和维护的独立配置文件数量。不过作者本人表示，出于可读性和快速定位的考虑，他更偏好使用分离的配置文件。
vp run 与任务缓存
vp run 可以执行 package.json 脚本和 Vite Task 工作流，包括依赖感知的任务执行与缓存。设想一个 monorepo：
my-company/
├── apps/
│ ├── web/
│ └── admin/
│
└── packages/
├── ui/
├── utils/
└── config/如果依赖链是 web → ui → utils，当 utils 发生变化时，部分任务需要重新运行；但如果相关文件没有变化，全部重跑就是浪费时间。这正是任务缓存发挥作用的地方：
vp run buildVite+ 能理解任务依赖关系，并在合适时复用缓存结果。这在大型仓库中比在小型演示应用中更有价值。另外，vpr 是 vp run 的独立简写形式。
真实的一天
综合来看，开发者的一天大致是这样：vp dev 开始工作，编写代码，vp check 检查，vp test 测试，vp build 构建，vp preview 预览。命令很简单，这是有意为之——复杂度从"记住几十条互不相关的命令"转移到了"拥有一套一致的工具链"。
更大的图景
没有统一工作流时，你可能面对的是 npm 之下挂着 Vite、Vitest、ESLint、Prettier、TypeScript、任务运行器和各种 package scripts。使用 Vite+ 后，底层技术依然存在，不同的是你与它们交互的方式：不再思考"这个该用哪个工具"，而是越来越多地思考"这个该用哪条 vp 命令"。
下一章将走出单个应用，讨论规模化场景下的 Vite+：monorepo、任务依赖、缓存、并行执行、CI/CD、共享配置，以及为什么 vp run 会随着仓库增长而变得更有价值。