Vite 3.0 发布公告
Vite 3.0 正式发布!
2022年7月23日 - 查看 Vite 4.0 发布公告
去年二月,Evan You 发布了 Vite 2。自此,其采用率持续增长,每周 npm 下载量已超过 100 万次。发布后迅速形成了一个庞大的生态系统。Vite 正在推动 Web 框架领域新一轮的创新竞赛。Nuxt 3 默认使用 Vite。SvelteKit、Astro、Hydrogen 和 SolidStart 均基于 Vite 构建。Laravel 现已决定默认使用 Vite。Vite Ruby 展示了 Vite 如何提升 Rails 的开发体验。Vitest 作为 Vite 原生的 Jest 替代方案正在取得长足进步。Vite 是 Cypress 和 Playwright 新组件测试功能的底层支持,Storybook 也已将 Vite 作为官方构建器。这样的例子不胜枚举。这些项目中的大多数维护者都积极参与改进 Vite 核心本身,与 Vite 团队 及其他贡献者紧密合作。

今天,距离 v2 发布 16 个月后,我们很高兴地宣布 Vite 3 正式发布。我们决定至少每年发布一次新的 Vite 主版本,以与 Node.js 的 EOL 保持一致,并借此机会定期审视 Vite 的 API,为生态系统中的项目提供简短的迁移路径。
快速链接:
如果您是 Vite 新手,建议阅读 为什么选择 Vite 指南。然后查看 快速开始 和 功能指南 了解 Vite 开箱即用的能力。一如既往,欢迎在 GitHub 上贡献代码。目前已有超过 600 位贡献者 帮助改进了 Vite。关注 Twitter 获取更新,或加入我们的 Discord 聊天服务器 与其他 Vite 用户交流。
全新文档
访问 vite.dev 即可体验全新的 v3 文档。Vite 现在采用了新的 VitePress 默认主题,带来了惊艳的深色模式等功能。

生态系统中的多个项目已经迁移到了这个新主题(参见 Vitest、vite-plugin-pwa 和 VitePress 本身)。
如果您需要访问 Vite 2 的文档,它们将保留在 v2.vite.dev。此外还有一个新的 main.vite.dev 子域名,Vite 主分支的每次提交都会自动部署到这里。这在测试 beta 版本或参与核心开发时非常有用。
现在还有了官方西班牙语翻译,加入了此前的中文和日文翻译:
Create Vite 起始模板
create-vite 模板是快速使用您喜爱的框架测试 Vite 的绝佳工具。在 Vite 3 中,所有模板都采用了与全新文档一致的新主题。立即在线打开并开始使用 Vite 3:
所有模板现在共享新主题。这有助于更好地传达这些起手模板的定位——作为开始使用 Vite 的最小模板。对于需要包含代码检查、测试设置等功能更完备的解决方案,一些框架有官方的 Vite 驱动模板,如 create-vue 和 create-svelte。社区维护的模板列表可在 Awesome Vite 找到。
开发体验改进
Vite CLI
VITE v3.0.0 ready in 320 ms ➜ Local: http://127.0.0.1:5173/ ➜ Network: use --host to expose
除了 CLI 界面的美化之外,您会注意到默认开发服务器端口现在是 5173,预览服务器端口为 4173。这一更改确保 Vite 避免与其他工具产生冲突。
改进的 WebSocket 连接策略
Vite 2 的一个痛点是在代理后运行时配置服务器。Vite 3 更改了默认连接方案,使其在大多数场景下开箱即用。所有这些配置现在都作为 Vite 生态系统 CI 的一部分,通过 vite-setup-catalogue 进行了测试。
冷启动改进
Vite 现在在冷启动期间,当插件在爬取初始静态导入模块时注入导入,可以避免完全重新加载 (#8869)。
点击了解更多
在 Vite 2.9 中,扫描器和优化器都在后台运行。在最佳情况下,扫描器能够发现所有依赖,冷启动时则无需重新加载。但如果扫描器遗漏了某个依赖,则需要新的优化阶段,然后进行重新加载。Vite 2.9 中,我们通过检测新的优化块是否与浏览器已有的块兼容,避免了其中一些重新加载。但如果存在公共依赖,子块可能会发生变化,从而需要重新加载以避免状态重复。在 Vite 3 中,优化的依赖在静态导入爬取完成之前不会交给浏览器。如果缺少依赖(例如由插件注入),则会发出一个快速的优化阶段,然后才发送打包后的依赖。因此,这些情况不再需要页面重新加载。
import.meta.glob
import.meta.glob 的支持已被重写。请在 Glob 导入指南 中阅读新特性:
多模式 可以以数组形式传递
js
import.meta.glob(['./dir/*.js', './another/*.js'])
现在支持否定模式(以 ! 为前缀)来忽略特定文件
js
import.meta.glob(['./dir/*.js', '!**/bar.js'])
可以指定命名导入 以改善 tree-shaking
js
import.meta.glob('./dir/*.js', { import: 'setup' })
可以传递自定义查询 以附加元数据
js
import.meta.glob('./dir/*.js', { query: { custom: 'data' } })
Eager 导入 现在作为一个标志传递
js
import.meta.glob('./dir/*.js', { eager: true })
对齐未来标准的 WASM 导入
WebAssembly 导入 API 已重新设计,以避免与未来标准冲突并使其更加灵活:
js
import init from './example.wasm?init'
init().then((instance) => {
instance.exports.test()
})
了解更多请参阅 WebAssembly 指南
构建改进
SSR 构建默认使用 ESM
生态系统中的大多数 SSR 框架已经在使用 ESM 构建。因此,Vite 3 将 ESM 作为 SSR 构建的默认格式。这使我们能够简化之前的 SSR 外部化启发式规则,默认情况下将依赖外部化。
改进的相对 Base 支持
Vite 3 现在正确支持相对 base(使用 base: ''),允许构建后的资源部署到不同 base 而无需重新构建。这在构建时 base 未知的情况下非常有用,例如部署到像 IPFS 这样的内容寻址网络时。
实验性特性
内置资源路径细粒度控制(实验性)
还有其他部署场景下这还不够。例如,如果生成的带哈希资源需要从公共文件部署到不同的 CDN,则需要在构建时对路径生成进行更细粒度的控制。Vite 3 提供了一个实验性 API 来修改构建后的文件路径。更多信息请查看 构建高级 Base 选项。
构建时的 Esbuild 依赖优化(实验性)
开发时和构建时的主要区别之一在于 Vite 如何处理依赖。在构建时,使用 @rollup/plugin-commonjs 来允许导入仅支持 CJS 的依赖(如 React)。使用开发服务器时,则改用 esbuild 来预打包和优化依赖,并在转换导入 CJS 依赖的用户代码时应用内联的 interop 方案。在 Vite 3 的开发过程中,我们引入了必要的更改,也允许在构建时使用 esbuild 优化依赖。这样就可以避免使用 @rollup/plugin-commonjs,使开发时和构建时的工作方式相同。
考虑到 Rollup v3 将在未来几个月内发布,并且我们随后会推出另一个 Vite 主版本,我们决定使此模式成为可选项,以缩小 v3 的范围,并让 Vite 和生态系统有更多时间来解决构建时新的 CJS interop 方法可能存在的问题。框架可以在 Vite 4 之前,按照自己的节奏切换为在构建时默认使用 esbuild 依赖优化。
HMR 部分接受(实验性)
现在可以选择性支持 HMR 部分接受。此功能可以为在同一模块中导出多个绑定的框架组件实现更细粒度的 HMR。您可以在此提案的讨论中了解更多信息。
包体积缩减
Vite 关注其发布和安装体积;快速安装新应用是一项特性。Vite 打包了其大部分依赖,并尽可能使用现代轻量级替代方案。延续这一持续目标,Vite 3 的发布体积比 v2 小了 30%。
| 发布体积 | 安装体积 | |
|---|---|---|
| Vite 2.9.14 | 4.38MB | 19.1MB |
| Vite 3.0.0 | 3.05MB | 17.8MB |
| 缩减 | -30% | -7% |
部分缩减是通过将一些大多数用户并不需要的依赖设为可选来实现的。首先,Terser 不再默认安装。自 Vite 2 中我们已经将 esbuild 设为 JS 和 CSS 的默认压缩器以来,这个依赖就不再需要了。如果您使用 build.minify: 'terser',则需要自行安装(npm add -D terser)。我们还将 node-forge 移出了 monorepo,将自动 https 证书生成的支持实现为一个新插件:@vitejs/plugin-basic-ssl。由于此功能只创建不受信任的证书且不会添加到本地存储,因此不值得增加包体积。
缺陷修复
由近期加入 Vite 团队的 @bluwyoo、@sapphi_red 牵头进行了一场问题分类马拉松。在过去的三个月里,Vite 的开放问题从 770 个减少到了 400 个。这一成绩是在新开启的 PR 数量达到历史最高水平的同时取得的。同时,@haoqunjiang 也整理了一份全面的 Vite 问题概览。


兼容性说明
- Vite 不再支持已到达 EOL 的 Node.js 12 / 13 / 15。现在需要 Node.js 14.18+ / 16+。
- Vite 现在以 ESM 形式发布,并带有 CJS 代理以兼容 ESM 入口。
- 现代浏览器基线现在针对支持原生 ES Modules、原生 ESM 动态导入 和
import.meta特性的浏览器。 - SSR 和库模式下的 JS 文件扩展名现在根据其格式和包类型,为输出的 JS 入口和块使用有效的扩展名(
js、mjs或cjs)。
了解更多请参阅迁移指南。
Vite 核心的升级
在向 Vite 3 迈进的过程中,我们还改善了贡献者参与 Vite Core 的体验。
- 单元测试和 E2E 测试已迁移到 Vitest,提供了更快、更稳定的开发体验。此举也是对生态系统中重要基础设施项目的 dogfooding。
- VitePress 构建现在作为 CI 的一部分进行测试。
- Vite 升级到 pnpm 7,与生态系统其他部分保持一致。
- Playgrounds 已从 packages 目录移至
/playgrounds。 - packages 和 playgrounds 现在是
"type": "module"。 - 插件现在使用 unbuild 打包,并且 plugin-vue-jsx 和 plugin-legacy 已迁移到 TypeScript。
生态系统已为 v3 做好准备
我们与生态系统中的项目密切合作,确保由 Vite 驱动的框架为 Vite 3 做好准备。vite-ecosystem-ci 使我们能够针对 Vite 主分支运行生态系统中领先项目的 CI,并在引入回归之前及时收到报告。今天的发布应该很快就会与大多数使用 Vite 的项目兼容。
致谢
Vite 3 是 Vite 团队 成员与生态系统项目维护者以及其他 Vite 核心贡献者集体努力的结果。
我们感谢所有为 Vite 3 实现功能、修复问题、提供反馈以及参与其中的人:
- Vite 团队成员 @youyuxi、@patak_dev、@antfu7、@bluwyoo、@sapphi_red、@haoqunjiang、@poyoho、@Shini_92 和 @retropragma。
- @benmccann、@danielcroe、@brillout、@sheremet_va、@userquin、@enzoinnocenzi、@maximomussini、@IanVanSchooten、Astro 团队 以及生态系统中所有其他帮助塑造 v3 的框架和插件维护者。
- @dominikg 在 vite-ecosystem-ci 上的工作。
- @ZoltanKochan 在 pnpm 上的工作,以及在我们需要支持时的积极响应。
- @rixo 对 HMR 部分接受的支持。
- @KiaKing85 为 Vite 3 发布准备好了主题,以及 @_brc_dd 对 VitePress 内部机制的贡献。
- @CodingWithCego 提供了新的西班牙语翻译,以及 @ShenQingchuan、@hiro-lapis 以及中文和日文翻译团队的其他成员,确保翻译文档保持最新。
我们还要感谢个人和公司对 Vite 团队的赞助,以及投资于 Vite 开发的公司:@antfu7 在 Vite 和生态系统上的部分工作是其 Nuxt Labs 工作职责的一部分,StackBlitz 雇佣了 @patak_dev 全职投入 Vite 开发。
下一步计划
我们将在接下来的几个月里确保所有基于 Vite 构建的项目平稳过渡。因此,最初的几个次要版本将专注于继续我们的问题分类工作,重点关注新开启的问题。
Rollup 团队正在开发其下一个主版本,将在未来几个月内发布。一旦 Rollup 插件生态系统有时间更新,我们将跟进发布新的 Vite 主版本。这将为我们带来今年引入更重大变更的又一次机会,我们可以借此巩固本次发布中引入的一些实验性特性。
如果您有兴趣帮助改进 Vite,最好的入门方式是帮助进行问题分类。加入我们的 Discord,寻找 #contributing 频道。或者参与我们的 #docs、#help 频道,亦或是创建插件。我们才刚刚开始,还有很多开放的想法来不断改进 Vite 的开发体验。
帮助我们改进文档
发现翻译问题或内容错误?请告诉我们。
