Vite 3.0 发布了!
2022年7月23日 - 查看 Vite 4.0 发布公告
去年二月,尤雨溪发布了 Vite 2。自那以后,它的采用率持续增长,每周 npm 下载量超过 100 万次。发布后,一个庞大的生态系统迅速形成。Vite 正在推动 Web 框架领域的创新竞赛。Nuxt 3 默认使用 Vite。SvelteKit、Astro、Hydrogen 和 SolidStart 均基于 Vite 构建。Laravel 现在也决定默认使用 Vite。Vite Ruby 展示了 Vite 如何改善 Rails 的开发体验(DX)。Vitest 作为 Jest 的 Vite 原生替代品,正在稳步前进。Cypress 和 Playwright 的新组件测试功能也采用了 Vite,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 主分支的提交都会自动部署到这里。这在测试测试版或参与核心开发时非常有用。
此外,现在还有官方的西班牙语翻译,它与之前的中文和日文翻译一同提供。
创建 Vite 启动模板
create-vite 模板是快速测试你最喜爱的框架与 Vite 兼容性的绝佳工具。在 Vite 3 中,所有模板都更新了与新文档相符的主题。现在就可以在线打开并体验 Vite 3 了。
该主题现在由所有模板共享。这有助于更好地传达这些入门套件作为 Vite 最小化启动模板的定位。对于包含 linting、测试设置和其他功能的更完整解决方案,一些框架提供了官方的 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-setup-catalogue 作为 Vite 生态系统 CI 的一部分进行测试。
冷启动改进
Vite 现在避免在冷启动时进行全页面重载,即使在爬取初始静态导入模块时有插件注入导入项的情况(#8869)。
点击了解更多
在 Vite 2.9 中,扫描器和优化器都在后台运行。在最佳情况下(扫描器能找到所有依赖项),冷启动时不需要重载。但如果扫描器漏掉了一个依赖项,则需要一个新的优化阶段,然后进行重载。Vite 在 v2.9 中能够避免一些重载,因为我们检测了新的优化块是否与浏览器已有的块兼容。但如果存在公共依赖,子块可能会发生变化,为了避免状态重复,需要进行重载。在 Vite 3 中,在完成静态导入的爬取之前,优化后的依赖项不会发送给浏览器。如果有缺失的依赖(例如由插件注入),会立即触发一个快速优化阶段,只有在此之后,捆绑好的依赖才会发送。因此,在这些情况下不再需要页面重载。
import.meta.glob
import.meta.glob 的支持已重写。请在 Glob 导入指南中了解新功能。
多重模式现在可以以数组形式传递。
import.meta.glob(['./dir/*.js', './another/*.js'])排除模式现在支持(以 ! 为前缀),用于忽略某些特定文件。
import.meta.glob(['./dir/*.js', '!**/bar.js'])命名导入可以指定,以改善 Tree-shaking。
import.meta.glob('./dir/*.js', { import: 'setup' })自定义查询可以传递以附加元数据。
import.meta.glob('./dir/*.js', { query: { custom: 'data' } })即时导入(Eager Imports)现在可以通过标志(flag)传递。
import.meta.glob('./dir/*.js', { eager: true })将 WASM 导入与未来标准对齐
WebAssembly 导入 API 已修订,以避免与未来标准冲突,并使其更加灵活。
import init from './example.wasm?init'
init().then((instance) => {
instance.exports.test()
})在 WebAssembly 指南中了解更多。
构建改进
默认采用 ESM SSR 构建
生态系统中的大多数 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 依赖项的用户代码时应用内联互操作方案。在 Vite 3 的开发过程中,我们引入了必要的更改,以允许在构建时也使用 esbuild 来优化依赖项。这样就可以避免使用 @rollup/plugin-commonjs,从而使开发和构建时的处理方式一致。
鉴于 Rollup v3 将在未来几个月内发布,且我们将紧随其后发布另一个 Vite 大版本,我们决定将此模式设为可选,以缩小 v3 的范围,并给 Vite 和生态系统更多时间来解决在构建时使用新 CJS 互操作方法可能出现的问题。框架可以在 Vite 4 之前按自己的节奏切换为默认使用 esbuild 依赖优化。
HMR 部分接受(实验性)
提供对 HMR 部分接受(HMR Partial Accept)的选择性支持。此功能可以为在同一模块中导出多个绑定的框架组件解锁更细粒度的 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。由于此功能仅创建未添加到本地存储的未信任证书,因此它不值得占据如此大的体积。
Bug 修复
由 @bluwyoo 和最近加入 Vite 团队的 @sapphi_red 带头进行了一场 Bug 修复马拉松。在过去三个月中,Vite 的公开问题从 770 个减少到 400 个。这一大幅下降是在新开 PR 数量达到历史新高的同时实现的。与此同时,@haoqunjiang 还整理了一份详尽的 Vite 问题概览。
兼容性说明
- Vite 不再支持已结束生命周期的 Node.js 12 / 13 / 15。现在要求 Node.js 14.18+ / 16+。
- Vite 现在作为 ESM 发布,并提供一个指向 ESM 入口的 CJS 代理以实现兼容性。
- 现代浏览器基准线现在瞄准支持 原生 ES 模块、原生 ESM 动态导入 和
import.meta特性的浏览器。 - SSR 和库模式下的 JS 文件扩展名现在根据格式和包类型使用有效的扩展名(
js、mjs或cjs)作为输出 JS 入口点和块。
在 迁移指南中了解更多。
对 Vite 核心的升级
在致力于 Vite 3 的同时,我们还改善了 Vite Core 协作者的贡献体验。
- 单元测试和 E2E 测试已迁移到 Vitest,提供了更快、更稳定的 DX。此举也为生态系统中的一个重要基础设施项目提供了“狗粮(dog fooding)”。
- 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 构建的项目顺利过渡。因此,最初的几个小版本(minor)将专注于继续进行问题分类,重点解决新提出的问题。
Rollup 团队正在开发其下一个大版本,将于未来几个月内发布。一旦 Rollup 插件生态系统有时间进行更新,我们将随之发布一个新的 Vite 大版本。这将为我们提供另一个机会,在今年内引入更重大的变更,从而稳定此版本中引入的一些实验性功能。
如果你有兴趣帮助改进 Vite,加入我们的最好方式是参与问题分类。加入我们的 Discord 并查找 #contributing 频道。或者参与我们的 #docs、帮助 #help 其他人,或创建插件。我们才刚刚起步。还有许多开放的创意可以继续改进 Vite 的开发体验。



