跳到主要内容

Vite+

Vite+ 不是给 Vite 多加几个命令这么简单。它想做的事情更大：把一个前端项目本来分散在不同工具里的开发、安装、检查、测试、构建和任务执行，尽量收进同一条链路。

如果项目里已经有这些东西：

  • Node 版本管理
  • 包管理器
  • Vite
  • Vitest
  • ESLint
  • Prettier
  • 构建器
  • monorepo task runner

那 Vite+ 的目标就很清楚了：把这些零散工具的入口统一起来，同时让它们尽量共享一套底层能力。

Vite+ 现在由什么组成​

根据 VoidZero 在 2026-03-13 发布的 Vite+ Alpha 说明，Vite+ 当前把这些能力收进了一起：

  • Vite
  • Vitest
  • Oxlint
  • Oxfmt
  • Rolldown
  • tsdown
  • Vite Task

同时，它还会照顾本地开发链路里另外两件常被单独管理的东西：

  • Node.js 运行时
  • 包管理器选择与安装

更直白一点，Vite+ 不只管“前端怎么构建”，也在试图接管“项目怎么跑起来”。

它具体做了什么​

1. 统一命令入口​

Vite+ Alpha 里最核心的命令是这些：

  • vp env
  • vp install
  • vp dev
  • vp check
  • vp test
  • vp build
  • vp run
  • vp pack
  • vp create

如果从团队协作角度看，这组命令的意义非常直观：项目成员不再需要先记住“安装用哪个工具、检查用哪套命令、monorepo 任务怎么跑、库怎么打包”。

2. 统一配置入口​

Vite+ 的一个重点，是尽量把配置收回到项目根目录的 vite.config.ts 里。

这意味着它不只是沿用 Vite 的开发服务器配置，还会把任务、检查、构建这类能力一起往这份配置文件靠。

3. 用 Vite Task 管 monorepo 任务​

官方把 Vite Task 作为 Vite+ 的核心组成之一。它主要做这些事：

  • 按依赖关系安排任务顺序
  • 自动追踪输入文件
  • 自动做本地缓存
  • 让 vp run 在 monorepo 里更像一个统一任务入口

这个方向非常像“把 Turborepo 这类任务系统的一部分能力收进来”，但又尽量让使用方式更贴近现有前端项目的直觉。

4. 用 Rust 工具链统一底层​

Vite+ 现在的一个明显特征，就是它把很多底层能力收到了 VoidZero 自家的 Rust 路线上：

  • Rolldown
  • Oxlint
  • Oxfmt
  • Oxc

这样做的目标很现实：减少“表面看起来工具统一了，底层其实还是分裂的”这种情况。

和老版本 Vite+ 的理解有什么区别​

2025-10-13 那版公开介绍里的 Vite+，还是一条更早期的产品形态。当时提到的是：

  • vite new
  • vite test
  • vite lint
  • vite fmt
  • vite lib
  • vite run
  • vite ui

到 2026-03-13 的 Alpha，主线已经更清晰，命令也统一到了 vp 这个入口上。

所以现在更稳的写法，应该以 Alpha 这套命令模型为主。

怎么安装​

官方在 Alpha 公告里给出的安装方式是：

macOS / Linux​

curl -fsSL https://vite.plus | bash

Windows PowerShell​

irm https://vite.plus/ps1 | iex

CI​

CI 环境官方建议用 setup-vp GitHub Action。

一个更接近日常开发的使用流程​

官方给出的流程大概是这样：

  1. 用 vp create 创建项目、monorepo，或者在 monorepo 里再加一个 app / package
  2. 用 vp install 安装依赖
  3. 用 vp dev 启动开发服务器
  4. 用 vp check 做类型检查、Lint、格式化
  5. 用 vp test 跑测试
  6. 用 vp build 出生产构建
  7. 用 vp run 跑脚本任务

这套流程最吸引人的地方，不在于“命令更短”，而在于团队协作时入口统一了很多。

前端项目怎么集成​

场景 1：从新项目开始​

这是最顺的一种方式。

  • 先用 vp create
  • 生成项目结构
  • 用 vp install
  • 再直接用 vp dev / check / test / build

这类项目不会背太多历史包袱，最容易把 Vite+ 的一体化体验吃满。

场景 2：已有 Vite 项目迁过来​

官方建议先升级到 Vite 8，再执行：

vp migrate

这个命令的定位很明确：把已有 Vite 或 VoidZero 工具链项目往 Vite+ 主线迁。

如果项目里已经用了这些东西中的一部分：

  • Vite
  • Vitest
  • Oxlint
  • Oxfmt
  • Rolldown-Vite

迁移成本通常会低一些。

场景 3：团队项目或 monorepo​

这类项目里，Vite+ 的价值往往不是单个应用构建更快，而是这些事情终于能一起管：

  • 统一 Node 版本
  • 统一包管理器策略
  • 统一 check 命令
  • 统一 monorepo 任务入口
  • 统一缓存与依赖执行顺序

这也是为什么 Vite+ 会把 vp run 和 Vite Task 放在这么核心的位置。

一个前端项目里最常见的接入方式​

如果项目本来就有 vite.config.ts，那通常不需要把整套配置推翻重写。更常见的是：

  • 原有 Vite 配置继续保留
  • 用 vp 接管开发入口
  • 逐步把检查、测试、任务执行迁过去

也就是说，Vite+ 更像是“在项目外层收工具链”，不是要求前端代码立刻大改。

vp check 为什么值得单独讲​

这条命令是 Vite+ 很有辨识度的一点。

它会把这些事情合到一起：

  • 类型检查
  • Lint
  • 格式化

如果是传统项目，这通常对应：

tsc --noEmit
eslint .
prettier --check .

Vite+ 的思路，是把这层流程直接做成默认工作流入口。对团队来说，这会比“每个仓库自己拼一套检查命令”整齐很多。

vp run 和 Vite Task 怎么配​

官方给的一个例子是：

export default defineConfig({
  run: {
    tasks: {
      'generate:icons': {
        command: 'node scripts/generate-icons.js',
        cache: true,
        envs: ['ICON_THEME'],
      },
    },
  },
})

这个例子背后的重点是：

  • 任务可以缓存
  • 输入变了才重跑
  • 环境变量也能进入缓存判断

如果项目里本来就有很多脚本任务，比如：

  • 生成图标
  • 生成路由
  • 导出 schema
  • 构建 design token

那这块会很有吸引力。

vp pack 适合什么​

这条命令更偏库和发布链路。

官方说法里，它既可以：

  • 打包 npm 库
  • 也可以产出独立 app binary

这一点说明 Vite+ 的目标不是只服务 Web 应用开发，它也在往“更完整的 JavaScript 工具链”那边走。

用 Vite+ 时最值得提前确认什么​

1. 当前项目是不是已经在 Vite 主线上​

如果不是，迁移路径会更长一些。

2. 团队是否愿意统一工具链​

Vite+ 的价值，只有在“项目真的准备把分散工具收起来”时才会放大。如果团队本身就不打算统一命令入口，那它的优势会打折。

3. 当前是否能接受 Alpha 性质​

截至 2026-03-13，Vite+ 官方说法仍然是 Alpha。这意味着：

  • 很值得关注
  • 很值得试
  • 但是否立刻大规模上生产，要看团队对新工具风险的接受度

一个更直接的判断​

如果当前只是想把 Vite 用好，先把 Vite 本身的配置、插件、构建和环境变量弄清楚就够了。

如果当前面对的是更大的问题，比如：

  • 团队工具链太碎
  • monorepo 任务太散
  • Lint / Format / Test / Build 各跑各的
  • Node 和包管理器在不同项目里经常漂移

那 Vite+ 就很值得认真看。