Vite+ Alpha + Rolldown 1.0：前端工具链终于要统一了？

前言：为什么前端工具链让人头疼

做前端项目稍微复杂一点，就会遇到一个让人头疼的问题：工具太多了。

构建工具需要配置 TypeScript，TypeScript 需要配置 tsconfig.json，Lint 需要配置 ESLint，代码格式化需要配置 Prettier，测试需要配置 Vitest，monorepo 需要配置 Turborepo/Nx/Lage...每个工具都有自己的配置体系和升级节奏。

这还没算上 CI 流程里的安装依赖、运行 lint、类型检查、执行测试、生产构建等一堆命令。配置文件的数量可能比业务代码还多。

问题的根源在于：JavaScript 生态的工具链一直是碎片化的。每个工具各司其职，但组合起来就会产生摩擦——版本不兼容、行为不一致、迁移成本高。

2026 年，这个问题终于开始得到系统性解决。

VoidZero 团队（Vite 背后的商业公司）在 2026 年连发大招：3 月发布 Vite 8，引入 Rust 编写的 Rolldown 作为统一打包器；同月发布 Vite+ Alpha，试图用一个 CLI 整合整个开发工具链；5 月 Rolldown 1.0 正式发布，API 锁定，生产就绪。

本文带你深入理解这波工具链变革的核心逻辑，以及如何平滑迁移到新架构。

Rolldown 1.0 核心特性

Rust 实现带来的性能飞跃

Rolldown 是一个 Rust 编写的 JavaScript 打包器，2026 年 5 月 7 日正式发布 1.0 版本，API 正式锁定。

性能是 Rolldown 最直观的优势。据官方数据，Rolldown 比 Rollup 快 10-30 倍，这个差距会随着项目规模增大而扩大。在基准测试中，Rolldown 的速度与 esbuild 持平。

实际生产数据更有说服力：

• Linear：生产构建时间从 46 秒降至 6 秒
• Ramp：构建时间减少 57%
• Beehiiv：构建时间减少 64%
• Mercedes-Benz.io：构建时间减少最高 38%

这些数字来自真实项目，不是实验室跑分。对于大型 monorepo 项目，这个性能提升意味着更快的 CI、更短的反馈循环。

Rolldown 的性能来源有几个层面：

Rust 原生执行：语言层面的性能优势，不需要 JVM 或其他运行时。

Oxc 深度集成：Rolldown 底层使用 Oxc 项目处理 JavaScript 解析、转换和压缩。Oxc 是 VoidZero 团队主导的 Rust 语言工具链，涵盖解析器、转换器、linter、formatter 等多个组件。

激进的 Dead Code Elimination：Rolldown 内置了 @__PURE__、@__NO_SIDE_EFFECTS__ 和 sideEffects 控制，配合智能常量内联和 TypeScript const enum 处理，可以生成更小的产物包。

更精细的分包控制：通过 advancedChunks 特性，可以实现类似 webpack 的精细化分包规则。据 Framer 团队反馈，使用这个特性后，chunk 大小减少了 67%。

Rollup 插件兼容：90%+ 插件开箱即用

Rolldown 的另一个核心设计目标是兼容 Rollup 插件 API。

Vite 的插件生态是建立在 Rollup 插件 API 之上的。如果 Rolldown 不能兼容这些插件，迁移成本会高到让大多数项目无法接受。

Rolldown 做到了 90%+ 的插件开箱即用。Vite 8 直接默认使用 Rolldown 作为打包器，大多数现有项目无需修改配置。

在插件兼容性上，Rolldown 还做了一些针对性优化：

Hook 过滤器优化：插件可以通过 id、code 或 moduleType 过滤器声明需要处理的范围。当过滤器不匹配时，Rolldown 可以跳过 Rust-to-JS 的跨语言调用，避免不必要的性能开销。

内置 Rust 插件：对于 replacePlugin 和 esmExternalRequirePlugin 这类常用插件，Rolldown 提供了 Rust 原生实现，可以直接使用而不需要 JS 依赖。

// rolldown.config.ts
import { defineConfig } from 'rolldown'
import { replacePlugin } from 'rolldown/plugins'

export default defineConfig({
  plugins: [
    replacePlugin({
      preventAssignment: true,
      values: {
        'process.env.NODE_ENV': JSON.stringify('production'),
      },
    }),
  ],
})

Rolldown 与 Rollup 的关系

Rolldown 不是要"杀死" Rollup，而是吸收了 Rollup 的插件 API 设计，并在此基础上添加了性能优势和新的特性。

Rollup 仍然是重要的项目，Rolldown 团队在官方文档中多次表达了感谢。可以这么理解：Rolldown 站在 Rollup 的肩膀上，解决了 Rollup 的性能痛点，同时保持了插件生态的兼容性。

对于插件作者来说，Rolldown 与 Rollup 的兼容性意味着：写一个 Rollup 插件，基本上就能同时用于 Vite/Rolldown 生态，不需要额外适配。

Vite 8 架构变革

旧架构的问题：开发正常，生产报错

Vite 从诞生起就采用了双打包器架构：

• 开发阶段：使用 esbuild 处理依赖预绑定、TypeScript/JSX 转换。esbuild 速度极快，让开发服务器的启动和 HMR 感觉"即时"。
• 生产阶段：使用 Rollup 进行打包、分包和优化。Rollup 的插件 API 设计优雅，生态丰富。

这个架构在 Vite 早期是合理的选择。2019 年 Vite 发布时，esbuild 证明了原生工具可以快一个数量级；Rollup 的插件生态则是 Vite 插件体系的基础。

但双打包器架构带来了根本性问题：

两套转换管线：esbuild 处理开发阶段，Rollup 处理生产阶段。两套管线的行为不可能完全一致，一些边界情况会导致"开发环境正常，生产环境报错"。

两套插件系统：开发插件基于 esbuild，生产插件基于 Rollup。同一个插件可能在两种环境下表现不同。

维护成本增加：需要大量胶水代码来协调两套管线。每次对齐一个功能的实现，都可能引入新的差异。

这些问题在项目规模较小时不明显，但随着项目增长，调试"为什么开发环境正常但生产环境报错"变成了一种折磨。

新架构：统一用 Rolldown

Vite 8 将开发和生产阶段的打包统一到 Rolldown：

Vite 7 架构：
开发服务器 → esbuild → 用户浏览器
生产构建 → Rollup → 优化产物

Vite 8 架构：
开发服务器 → Rolldown → 用户浏览器
生产构建 → Rolldown → 优化产物

统一打包器后，开发和生产的行为一致性大幅提升。同一个转换管线、同一个插件 API，边界情况大幅减少。

Node.js 版本要求提升到 20.19+ 或 22.12+，因为 Vite 8 全面转向 ESM 分发，不再需要 require(esm) 的兼容性处理。

安装大小的变化

需要注意的是，Vite 8 的安装大小增加了约 15MB：

• ~10MB 来自 lightningcss：之前是可选的 peer dependency，现在成为正常依赖，提供更好的 CSS 压缩能力。
• ~5MB 来自 Rolldown：Rolldown 二进制文件比 esbuild + Rollup 组合略大，主要是性能优先的设计选择。

对于现代开发流程，这个安装大小的增加影响有限——CI 环境通常有缓存，开发机器的磁盘空间也不是瓶颈。

Vite 8 的其他新特性

除了 Rolldown 集成，Vite 8 还带来了一些值得注意的新特性：

集成 Devtools：新增 devtools 配置选项，可以启用 Vite Devtools，提供更深入的调试和分析能力。

内置 tsconfig paths 支持：设置 resolve.tsconfigPaths: true 可以让 Vite 直接读取 tsconfig.json 中的 paths 配置，不需要额外插件。略有性能开销，默认不开启。

emitDecoratorMetadata 支持：Vite 8 原生支持 TypeScript 的 emitDecoratorMetadata 选项，装饰器密集的框架（如 Angular、NestJS）不再需要额外配置。

Wasm SSR 支持：.wasm?init 导入现在可以在 SSR 环境中工作，WebAssembly 特性扩展到服务端渲染。

浏览器控制台转发：server.forwardConsole 选项可以将浏览器控制台日志转发到 dev 服务器终端，对于使用 coding agent 的场景特别有用。

Full Bundle Mode（实验性） ：这是 Vite 8 最具前瞻性的功能。当前的开发服务器采用"不打包"模式，按需加载各个 ESM 模块。对于超大型项目，这会导致大量网络请求和较慢的页面加载。Full Bundle Mode 在开发阶段也进行完整打包，类似生产构建。初步测试数据显示：启动速度快 3 倍、全量重载快 40%、网络请求减少 90%。

Vite+ Alpha：统一工具链入口

为什么需要 Vite+

Vite 8 解决了打包器统一的问题，但前端项目的工具链远不止打包器。

一个典型项目可能需要：

• Node.js 版本管理
• 包管理器（pnpm/npm/yarn）
• 开发服务器（Vite）
• 类型检查（TypeScript/tsgo）
• Lint（ESLint）
• 代码格式化（Prettier）
• 测试（Vitest）
• 生产构建（Rolldown/Oxc）
• monorepo 任务管理（Turborepo/Nx/Lage）

每个工具都有自己的 CLI、配置文件和升级节奏。工具之间需要协调，但没有人对整体体验负责。

Vite+ 是 VoidZero 团队对这个问题的系统性回答：提供一个统一的入口，管理整个开发流程。

Vite+ 的构成

Vite+ 将多个工具整合到一个工具链中：

表格

组件	工具	说明
开发服务器	Vite 8	基于 Rolldown 的快速开发体验
测试框架	Vitest 4.1	与 Vite 深度集成的测试框架
Lint	Oxlint	比 ESLint 快 50-100 倍
格式化	Oxfmt	比 Prettier 快 30 倍
打包器	Rolldown	Rust 编写的生产打包器
类型检查	tsgo	基于 Oxc 的快速类型检查
任务运行	Vite Task	支持缓存和依赖感知的任务编排
库打包	tsdown	专门用于库发布的打包工具

所有这些工具都基于 Rust 实现或深度集成 Rust 工具链，性能表现优异。

核心命令

Vite+ 的 CLI 叫 vp（Vite Plus 的缩写）。日常工作流都可以通过这个命令完成：

# 环境管理：Node.js 全局/项目级别管理
vp env use 22

# 依赖安装：自动识别并使用正确的包管理器
vp install

# 开发服务器：基于 Vite 的快速开发体验
vp dev

# 代码检查：同时运行 Oxlint、Oxfmt、tsgo
vp check
vp check --fix  # 自动修复格式和 lint 问题

# 测试：运行 Vitest
vp test

# 生产构建：使用 Rolldown 和 Oxc
vp build

# 任务执行：执行 package.json 脚本，支持缓存
vp run <name>

# 打包发布：库发布或独立应用打包
vp pack

# 项目创建：脚手架新项目或 monorepo
vp create

MIT 开源的决定

Vite+ 在 2026 年 3 月 13 日以 MIT 许可证开源。这是一个值得关注的决定。

在 Alpha 发布之前，VoidZero 团队曾考虑过商业授权模式：个人开发者免费，企业/团队需要付费。这个模式在基础设施领域很常见。

但最终，VoidZero 选择 MIT 许可证，完全开源、免费。这个决定降低了采用门槛，也符合 Vite 一直以来的开源精神。

据 VoidZero 公告，团队在 2025 年 10 月宣布商业化计划后，收到了大量社区反馈，最终决定改变策略。Vite+ 的开源意味着任何个人或公司都可以自由使用和修改。

Vite Task：更智能的任务编排

Vite Task 是 Vite+ 内置的任务运行器，目标是替代 monorepo 中常用的 Turborepo/Nx 等工具。

Vite Task 的核心特性：

自动化输入追踪：任务运行器会自动追踪命令使用的输入文件，确定哪些内容应该被缓存。如果输入没有变化，直接回放输出，跳过实际执行。

依赖感知执行：任务按照正确的依赖顺序执行，确保 build -> test -> lint -> typecheck 这样的流程自动协调。

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

Vite+ 与现有 Vite 生态的关系

Vite+ 不会取代 Vite。Vite 仍然是构建工具，Vite+ 是构建在 Vite 之上的工具链层。

现有的 Vite 插件和配置继续工作。Vite+ 提供了统一的入口和默认配置，但不强制改变项目的现有结构。

对于框架（React、Vue、Svelte、Nuxt、Astro）来说，Vite+ 也是兼容的。VoidZero 在设计 Vite+ 时明确表示，它与所有 Vite 生态框架兼容。

Rust 三大打包器格局

打包器的战国时代

2026 年，JavaScript 打包器进入了"战国时代"。多个 Rust 编写的打包器同时存在，各有定位：

表格

打包器	定位	主要用户
Rolldown	框架无关，Vite 生态	Vue、React 等框架项目
Rspack	Webpack 迁移	大量 Webpack 遗留项目
Turbopack	Next.js 专用	Vercel 生态

理解这三个打包器的定位，有助于判断技术趋势。

Rolldown：框架无关的通用方案

Rolldown 由 VoidZero 团队开发，是 Vite 8 的默认打包器。设计上框架无关，但因为 Vite 的普及度，实际上与 Vue、React、Svelte 等主流框架都有深度集成。

Rolldown 的优势：

• Rollup 插件 API 兼容，生态丰富
• 性能与 esbuild 持平
• Vite 8 默认采用，有大量生产验证
• API 稳定，1.0 版本已锁定

Rolldown 的劣势：

• 相对年轻（2024 年才发布首个版本）
• 某些特定场景（如特别复杂的 Webpack 配置迁移）可能不如 Rspack

Rspack：Webpack 迁移利器

Rspack 由 ByteDance 团队开发，目标是帮助 Webpack 用户平滑迁移到现代打包器。

Rspack 的核心优势是与 Webpack 的兼容性。据官方数据，Rspack 与 Webpack 的 API 兼容性达到 ~95%，可以处理绝大多数 Webpack 配置。

// Rspack 配置可以直接使用 Webpack 配置风格
import { defineConfig } from '@rspack/cli'

export default defineConfig({
  entry: './src/index.ts',
  output: {
    filename: 'main.js',
  },
  module: {
    rules: [
      {
        test: /.tsx?$/,
        use: 'babel-loader',
      },
    ],
  },
})

对于有大量 Webpack 配置遗留的项目，Rspack 是务实的选择。不需要重写所有配置，可以渐进式迁移。

Turbopack：Next.js 的绑定

Turbopack 由 Vercel 团队开发，2020 年发布 Beta，目标之一是替代 Webpack。Turbopack 与 Next.js 深度绑定，是 Vercel 部署平台的默认打包器。

Turbopack 的特点：

• 与 Next.js 深度集成
• Rust 实现，性能优秀
• 但生态相对封闭，主要服务 Vercel 生态

Turbopack 与 Vite 的关系值得关注。Next.js 15 曾经尝试引入 Turbopack 作为可选打包器，但迁移进展缓慢。Vercel 和 Vite 团队之间的关系也值得玩味。

格局演变的判断

从当前趋势看，Rolldown 正在成为最大变量：

1. Vite 8 的默认采用：所有使用 Vite 的项目都会受益于 Rolldown，这意味着 Rolldown 将在大量项目中部署。
2. 生态整合：Vite+ 的推出进一步加强了 Rolldown/Vite 生态的完整性。Oxc 的 linting/formatting/minification 都与 Rolldown 协同工作。
3. 开放生态：Rolldown 坚持 MIT 许可证，Rolldown-vite 插件可以独立使用，不强制绑定到特定框架或平台。
4. Rspack 团队的态度：Rspack 社区已经在讨论与 Rolldown 的协同可能性。对于 Rspack 用户来说，这意味着未来的迁移路径更清晰。

Turbopack 的处境相对尴尬。如果 Next.js 最终选择拥抱 Rolldown（通过某种方式集成），Turbopack 可能需要重新定位。

升级实战：Vite 7 到 Vite 8 迁移指南

升级路径选择

对于大多数项目，Vite 8 的迁移应该是平滑的。Vite 团队提供了兼容层，会自动转换现有的 esbuild 和 rollupOptions 配置到 Rolldown/Oxc 对应配置。

但对于大型或复杂的项目，建议分两步走：

第一步：在 Vite 7 上测试 rolldown-vite
npm install rolldown-vite@7

# 修改 vite.config.ts
// Vite 7 默认导出
import { defineConfig } from 'vite'

// 切换到 rolldown-vite
import { defineConfig } from 'rolldown-vite'

export default defineConfig({
  // 现有配置...
})

这个临时包允许你在 Vite 7 的基础上测试 Rolldown，隔离打包器问题和其他 Vite 8 变化。

第二步：升级到 Vite 8
npm install vite@^8.0.0

配置迁移：rollupOptions 到 rolldownOptions

最明显的配置变化是 build.rollupOptions 改为 build.rolldownOptions。

// Vite 7 配置
import { defineConfig } from 'vite'

export default defineConfig({
  build: {
    rollupOptions: {
      external: ['vue'],
      output: {
        // manualChunks 的对象形式
        manualChunks: {
          vendor: ['react', 'react-dom'],
        },
      },
    },
  },
})

// Vite 8 配置
import { defineConfig } from 'vite'

export default defineConfig({
  build: {
    rolldownOptions: {
      external: ['vue'],
      output: {
        // manualChunks 被 advancedChunks 替代
        advancedChunks: {
          groups: [
            {
              name: 'vendor',
              test: /react/,
            },
          ],
        },
      },
    },
  },
})

advancedChunks 提供了更精细的分包控制，语法借鉴自 webpack 的 splitChunks。

配置迁移：esbuild 到 oxc

Vite 7 使用 esbuild 处理 JSX 转换。Vite 8 迁移到 Oxc。

// Vite 7 配置
import { defineConfig } from 'vite'

export default defineConfig({
  esbuild: {
    jsxFactory: 'h',
    jsxFragment: 'Fragment',
  },
})

// Vite 8 配置
import { defineConfig } from 'vite'

export default defineConfig({
  oxc: {
    jsx: {
      runtime: 'classic',
      pragma: 'h',
      pragmaFrag: 'Fragment',
    },
  },
})

字段名略有变化：jsxFactory → pragma，jsxFragment → pragmaFrag。

Breaking Changes 清单

表格

变更项	Vite 7	Vite 8	应对方案
默认浏览器目标	Chrome 107	Chrome 111	如需覆盖，在 browserTargets 中显式指定
CJS 互操作	较宽松	更严格	添加 legacy.inconsistentCjsInterop: true
manualChunks 对象形式	支持	已移除	改用 advancedChunks
esbuild.minify	支持	已弃用	迁移到 Oxc minifier
transformWithEsbuild	支持	已弃用	改用 transformWithOxc

框架特定注意事项

React

@vitejs/plugin-react v6 默认使用 Oxc 替代 Babel 作为 React Refresh 转换。v5 仍然兼容 Vite 8，所以可以先升级 Vite，再升级插件。

如果需要 React Compiler（React 19 的实验特性），v6 提供了 reactCompilerPreset helper，与 @rolldown/plugin-babel 配合使用。

Svelte

Svelte 团队建议使用 pnpm overrides 锁定 Vite 版本：

{
  "pnpm": {
    "overrides": {
      "vite": "^8.0.0"
    }
  }
}

Nuxt

Nuxt 3/4 基于 Vite 构建，官方会提供迁移指南。在 Vite 8 发布前，Nuxt 团队已经参与了 beta 测试。

Astro

Astro 同样基于 Vite 构建。Astro 团队表示会配合 Vite 8 节奏更新依赖。

Cloudflare Workers

chunk 文件名计算方式变化可能导致缓存失效。部署时需要清理旧缓存。

验证迁移

升级后，运行以下命令验证：

# 启动开发服务器
vp dev

# 生产构建
vp build

# 检查构建产物
ls dist/

# 运行测试（如有）
vp test

如果遇到问题，首先检查是否有自定义插件不兼容。Rolldown 兼容 90%+ 的 Rollup 插件，但极端情况可能有问题。

Vite+ 尝鲜指南

安装 Vite+

Vite+ 以单个二进制分发，安装非常简洁：

# macOS / Linux
curl -fsSL https://vite.plus | bash

# Windows (PowerShell)
irm https://vite.plus/ps1 | iex

安装后，vp 命令全局可用。打开新终端会话验证：

vp --version

对于 CI 环境，使用 GitHub Action setup-vp。

迁移现有项目

Vite+ 提供了 vp migrate 命令，可以帮助迁移现有项目：

# 在项目根目录执行
cd my-project
vp migrate

migrate 会分析项目结构，生成推荐的 Vite+ 配置，包括：

• 识别包管理器
• 检测现有 lint/format 配置
• 生成 vite.config.ts

对于 Agent（Claude Code、Codex 等），Vite+ 提供了专门的迁移 prompt，可以在 Vite+ 生成的 AGENTS.md 文件中找到。

创建新项目

Vite+ 的项目脚手架会自动配置所有工具：

vp create

交互式命令会询问：

• 项目类型（单仓库/monorepo）
• 使用的框架（React、Vue、Svelte 等）
• 其他偏好设置

创建完成后，项目已经配置好 pre-commit hooks，可以立即开始开发。

体验 vp check 的速度

最能体现 Vite+ 优势的场景是 vp check：

# 同时运行 type-check、lint、format
vp check

# 自动修复格式和 lint 问题
vp check --fix

背后的工具链：

• Oxlint：比 ESLint 快 50-100 倍
• Oxfmt：比 Prettier 快 30 倍
• tsgo：基于 Oxc 的类型检查，比 tsc 快

对于大型 monorepo，这个速度提升对开发体验影响显著。

当前版本的局限性

Vite+ 仍然处于 Alpha 阶段，需要注意以下限制：

Oxlint 插件支持：Oxlint 尚未完全兼容所有 ESLint 插件。Vue 和 React 生态的一些常用插件可能需要等待支持。

Oxfmt 兼容性：Oxfmt 处于 Beta，报告的 Prettier 兼容性超过 95%，但剩余的 5% 可能正好是你的用例。

Vite Task 缓存：当前只缓存终端输出，不存储输出文件。对于某些任务场景可能不够。

版本稳定性：Alpha 版本更新频繁，API 可能变化。生产项目建议锁定版本。

写在最后

2026 年的前端工具链正在经历一场深刻的变革。Rust 编写的打包器（Rolldown）解决了 JavaScript 打包器的性能瓶颈；Vite 8 通过统一打包器解决了开发/生产行为不一致的老问题；Vite+ 则尝试用一个 CLI 整合整个开发流程。

这些变化的共同趋势是：工具链的复杂性正在被系统性降低。

过去，配置前端项目需要理解大量独立工具的配置语法和升级节奏。现在，VoidZero 团队提供的这套工具链——Vite + Rolldown + Oxc——正在成为 Opinionated 的默认选择。一个配置文件、一套默认配置、一个 CLI 命令，可以覆盖大部分开发需求。

对于 Vue/TypeScript 开发者来说，这是好消息。Vite 生态与 Vue 的深度绑定意味着 Vue 项目会第一时间受益于这些改进。Rolldown 的性能提升、Oxc 的快速 linting/formatting，对日常开发体验的提升是实打实的。

迁移建议：

1. 立即可做：在非核心项目上测试 Vite 8，观察是否有兼容性问题
2. 近期计划：关注 Vite+ Alpha 的进展，特别是 vp check 和 Vite Task
3. 长期观察：Rolldown 1.0 的生态建设，特别是 Full Bundle Mode 的稳定性

技术选型永远需要在"尝鲜"和"稳定"之间找平衡。Vite 8 的兼容层设计得很好，大多数项目可以平滑迁移；Vite+ 虽然是 Alpha，但 MIT 开源的决定降低了长期风险。

唯一确定的是：JavaScript 工具链的统一趋势已经开始了。

信息来源：

• Announcing Rolldown 1.0
• Vite 8.0 is out!
• Announcing Vite+ Alpha
• Everything You Need to Know about Vite 8, Vite+, and Void

本文由AI辅助整理