尤雨溪宣布 Vite+ 正式开源,前端工具链要大一统了

我正在开发 DocFlow,它是一个完整的 AI 全栈协同文档平台。该项目融合了多个技术栈,包括基于 Tiptap 的富文本编辑器、NestJs 后端服务、AI 集成功能和实时协作。在开发过程中,我积累了丰富的实战经验,涵盖了 Tiptap 的深度定制、性能优化和协作功能的实现等核心难点。

如果你对 AI 全栈开发、Tiptap 富文本编辑器定制或 DocFlow 项目的完整技术方案感兴趣,欢迎加我微信 yunmz777 进行私聊咨询,获取详细的技术分享和最佳实践。

如果你对 AI全栈 感兴趣,也欢迎添加我微信,我拉你进交流群

3 月 13 日深夜,尤雨溪在 X 上发了一条推文,平静地宣布了一件大事。

We are happy to announce that Vite+ is now fully open source under MIT license. Free for everyone!

Vite+ 以 MIT 协议全量开源,所有人免费使用。官网已经上线,地址是 viteplus.dev

如果说 Vite 8 的发布是"换了个引擎",那 Vite+ 的开源就是直接掀了桌子。它不是 Vite 的升级版,而是一个全新的物种,一个二进制文件,吃掉你整条前端工具链。

Vite+ 到底是什么

官网给出的定位很直白,"The Unified Toolchain for the Web"。

一句话来说,Vite+ 是一个统一的 Web 开发工具链,把 ViteVitestOxlintOxfmtRolldowntsdownVite Task 七个项目合并成了一个 CLI,命令叫 vp

它的野心不小。管构建,管运行时,管包依赖,管代码检查,管格式化,管测试,管打包发布,甚至管 monorepo 的任务编排。以前你需要 npmpnpmViteESLintPrettierJestnvm 各自配置、各自维护,现在一个 vp 全包了。

值得注意的是,Vite+ 是两段式设计:vp 是全局安装的命令行工具,vite-plus 是每个项目里安装的本地包。这两者协同工作,vp 负责统一入口,vite-plus 负责具体的构建逻辑。

完整命令地图

vp 的命令覆盖了开发全流程,分成几个维度来看:

启动和初始化

命令 做什么
vp create 创建新项目(支持 app、包、monorepo 模板)
vp migrate 把现有项目迁移到 Vite+
vp env 管理 Node.js 版本
vp install 用正确的包管理器安装依赖
vp config 配置 commit hooks 和 agent 集成

日常开发

命令 做什么 替代谁
vp dev 开发服务器,即时 HMR vite dev
vp check 类型检查 + Lint + 格式化 tscESLintPrettier
vp lint 单独运行 Lint ESLint
vp fmt 单独运行格式化 Prettier
vp test 运行测试 JestVitest
vp staged 对暂存文件跑检查 lint-staged

构建和发布

命令 做什么 替代谁
vp build 生产构建 vite build
vp preview 本地预览生产构建 vite preview
vp pack 库打包 + DTS 生成 tsuptsdown
vp run monorepo 任务执行(带缓存) turboreponx

依赖管理

命令 做什么
vp add / vp remove / vp update 包管理操作
vp dedupe / vp outdated / vp why 依赖分析
vp dlx 不安装直接运行包(类似 npx
vpx 全局执行二进制

还有一个彩蛋命令,vp implode,它会把 vp 本身和所有相关数据从机器上清除干净,如果用了之后觉得不适合自己,一条命令可以走得一干二净。

官网 viteplus.dev 首页的终端示例里,用 vp create acme-web --template react-ts 创建 React + TypeScript 项目,从脚手架生成到依赖安装完成,显示耗时 1.1 秒。

性能数字很夸张

Vite+ 的底层全部用 Rust 重写,官方给出的性能对比数据:

  • 生产构建比 webpack 快 40 倍(基于 Vite 8 + Rolldown
  • OxlintESLint 快 50 到 100 倍
  • OxfmtPrettier 快 30 倍
  • 开发时 HMR 始终保持即时响应

这些数字不是 Vite+ 团队自己编的。OxlintOxfmtOxc 项目里已经跑了很久的 benchmark,社区早有验证。Vite+ 做的事是把这些分散的高性能工具统一到了一个入口。

vp check 不只是 Lint

vp check 是这个工具链里设计最有意思的命令之一,值得单独说说。

它把三件事合进一个命令:Oxfmt 负责格式化,Oxlint 负责代码检查,tsgolint 负责 TypeScript 类型检查。三个工具并行跑,比分别执行快得多。

当你在 vite.config.ts 里开启 typeCheck 选项后,vp check 还会接入 TypeScript Go 工具链做类型感知的静态分析,这是微软正在推进的下一代 TypeScript 编译器,速度比原来的 tsc 快了一个数量级。

typescript 复制代码
import { defineConfig } from 'vite-plus'

export default defineConfig({
  lint: {
    options: {
      typeAware: true,
      typeCheck: true,
    },
  },
})

开启之后,一条 vp check 就能搞定格式、Lint、类型三重检查。加上 --fix 参数还能自动修复可修复的问题:

bash 复制代码
vp check        # 检查
vp check --fix  # 检查并自动修复

一个配置文件管所有

以前的前端项目,配置文件能铺满项目根目录,vite.config.ts.eslintrc.prettierrcvitest.config.tstsconfig.jsonlint-staged.config.js......

Vite+ 的做法是把所有配置收拢到一个 vite.config.ts

typescript 复制代码
import { defineConfig } from 'vite-plus'

export default defineConfig({
  // 开发服务器
  server: { port: 3000 },

  // Oxlint 规则
  lint: {
    options: {
      typeAware: true,
      typeCheck: true,
    },
  },

  // Oxfmt 格式化
  fmt: { /* ... */ },

  // Vitest 测试
  test: { /* ... */ },

  // 任务编排
  tasks: { /* ... */ },

  // commit 前的暂存检查(替代 lint-staged)
  staged: {
    '*.{js,ts,tsx,vue,svelte}': 'vp check --fix',
  },

  // 库打包(替代 tsdown.config.ts)
  pack: {
    entry: ['src/index.ts'],
    dts: true,
    format: ['esm', 'cjs'],
  },
})

一个文件,一套类型提示,一个 IDE 插件搞定所有配置的智能补全。对于强迫症开发者来说,这可能比性能提升更让人兴奋。

vp env 能精细管理 Node 版本

nvm 的用户应该对这种场景很熟悉,不同项目需要不同版本的 Node,切换还容易忘。

vp env 的设计是让 nodenpm 等命令都通过 Vite+ 的 shim 来走,自动识别当前项目锁定的 Node 版本,无需手动切换。

常用命令:

bash 复制代码
vp env pin lts          # 把项目锁定到最新 LTS 版本(写入 .node-version)
vp env use 20           # 当前 shell 会话临时切换到 Node 20
vp env default lts      # 设置全局默认版本
vp env current          # 查看当前解析到的环境
vp env doctor           # 运行环境诊断,排查问题
vp env list             # 列出本地已安装的版本
vp env list-remote --lts  # 查看可安装的 LTS 版本列表

如果你不想让 Vite+ 接管 Node 版本管理,可以用 vp env off 切到"系统优先"模式,Vite+ 只在系统 Node 找不到时才接管。

现有项目怎么迁移

这是官网里最有价值的部分之一,也是原文没有覆盖到的内容。

对于已有的 Vite 项目,迁移命令是:

bash 复制代码
vp migrate

这条命令会自动完成:把各个工具的分散配置合并进 vite.config.ts,更新项目依赖,重写 vitevitest 的导入路径,更新 package.json 里的 scripts。

官方建议的迁移前准备:先升级到 Vite 8+ 和 Vitest 4.1+,了解现有的 Lint、格式化、测试配置。迁移后跑一遍验证:

bash 复制代码
vp install
vp check
vp test
vp build

有意思的一个细节,官网的迁移文档里提供了一段专门写给 AI 编码助手的 migration prompt,可以直接粘贴给 Cursor 或 Claude 来代劳整个迁移过程。这说明 Vite+ 团队在设计工具时已经把 AI 辅助开发纳入考虑了。

不止是 Vue 生态的事

Vite+ 支持的框架列表相当长,包括 ReactVueSvelteSolidAstroNuxtNext.jsRemix,官网列了超过 20 个框架。

这意味着它不是"Vue 生态的专属工具"。任何前端框架的开发者都可以用,而且迁移成本几乎为零,因为底层就是 Vite,现有的 Vite 插件理论上都能直接用。

部署方面,Vite+ 可以与 Nitro 配合,直接部署到 VercelNetlifyCloudflareRender 等平台,从 SPA 到全栈 meta 框架都有完整支持。

怎么装

macOS 或 Linux 下:

bash 复制代码
curl -fsSL https://vite.plus | bash

Windows(PowerShell)下:

bash 复制代码
irm https://vite.plus/ps1 | iex

装完就是一个独立二进制文件,不依赖 Node.js 全局安装,不需要 npm install -g。安装后打开新的终端窗口,运行 vp help 就能看到所有命令。在 CI 环境里可以用官方提供的 setup-vp Action。

运行 vp upgrade 可以更新 vp 本身到最新版本。

谁在做这件事

Vite+ 背后是 VoidZero,尤雨溪在 2024 年创立的公司,专注于 Web 工具链。核心团队成员里有几个名字值得关注:

  • 尤雨溪,Vue.jsVite 的创造者
  • LONG Yinan,Oxc 项目的核心作者,Rust 工具链领域的资深开发者
  • Christoph Nakazawa,前 Meta 工程师,Jest 的创造者

没错,Jest 的创造者现在在给 Vite+ 写测试框架。这个阵容不需要多解释。

GitHub 仓库显示,Vite+ 的代码库有 608 个 commit,62.9% 是 Rust,33.4% 是 TypeScript。目前最新版本是 v0.1.11,处于 Alpha 阶段。

Vite 本身每周 npm 下载量已达 6900 万次,GitHub 星标 78.7K,是前端构建工具的事实标准。Vitest 每周下载量也超过 3500 万。这套工具链的用户基数不需要从零积累。

商业模式

很多人关心的问题,这么大的项目,免费能持续多久?

VoidZero 的做法是,Vite+ 完全开源,MIT 协议,永久免费。公司的营收来源是另一个独立的商业产品 Void,具体形态还没公开,但大概率是面向企业的增强版或云服务。

这和 VercelNext.js 免费,平台收费)的路线类似,开源工具做增长飞轮,商业产品做营收。这条路已经被验证过了。

现阶段要注意的几点

虽然 Vite+ 的愿景很性感,但当前有几个现实问题值得正视。

第一,它现在是 Alpha 版本。v0.1.11,连 Beta 都没到,API 可能随时调整,生产环境请三思。官方文档里也明确说了,vp migrate 运行完之后大多数项目还需要手动调整,不是一键无缝。

第二,"大一统"是双刃剑。统一工具链的好处是减少配置和兼容性问题,但坏处是一旦某个模块出问题,整条链都可能受影响。以前 ESLint 出错不影响构建,以后就不好说了。

第三,生态兼容性需要时间。虽然理论上兼容 Vite 插件,但实际使用中肯定会有各种边界情况,社区插件的适配需要一个过程。

第四,包管理这块水很深。npmpnpmyarn 打了很多年,每家都有自己的 resolve 策略和 lockfile 格式,Vite+ 要在这个领域站稳脚跟,挑战不小。

这件事的意义

前端工具链的碎片化问题困扰社区很久了。一个新项目光配置工具链就要半天,node_modules 动辄几百 MB,各种工具之间的版本冲突是家常便饭。

Vite+ 的出现代表了一种趋势,用 Rust 重写性能敏感的部分,用统一的入口消除工具之间的缝隙。

类似的尝试不止 Vite+ 一家,BunDenoBiome 都在做类似的事。但 Vite+ 有一个独特优势,它站在 Vite 的肩膀上,从 ViteVite+ 的迁移路径是最短的,用户基数也是最大的。

从现在的角度来看,Alpha 阶段先关注、多试用、遇到问题提 issue 才是正确姿势。但这件事本身值得认真看待,前端工具链可能真的要变了。

相关推荐
喵叔哟1 小时前
5. 【Blazor全栈开发实战指南】--Blazor组件基础
开发语言·javascript·ecmascript
sunny_2 小时前
📖 2026年 大厂前端面试手写题库已开源(2.3k star)
前端·面试·github
IT_陈寒2 小时前
Vue组件复用率提升300%?这5个高阶技巧让你的代码焕然一新!
前端·人工智能·后端
We་ct2 小时前
LeetCode 79. 单词搜索:DFS回溯解法详解
前端·算法·leetcode·typescript·深度优先·个人开发·回溯
ujainu2 小时前
Electron 实战:将用户输入保存到本地文件 —— 基于 `fs.writeFileSync` 与 IPC 的安全写入方案
javascript·安全·electron
小奶包他干奶奶3 小时前
将svg对象化,并动态修改svg图标的颜色、尺寸等
前端·html
Lee川3 小时前
React 快速入门:Vue 开发者指南
前端·vue.js·react.js
进击的尘埃3 小时前
基于 LangChain.js 的前端 Agent 工作流编排:Tool 注册、思维链可视化与多步推理的实时 DAG 渲染
javascript
用户6158139695163 小时前
Elpis: 基于vue3+webpack5+nodejs搭建一个完整项目
前端