Vite 5.1 发布公告

2024 年 2 月 8 日

Vite 5 于去年 11 月发布，对 Vite 和整个生态系统来说，这又是一次巨大的飞跃。几周前，我们庆祝了 Vite 的周 npm 下载量突破 1000 万次，以及 Vite 仓库迎来 900 位贡献者。今天，我们很高兴地宣布 Vite 5.1 正式发布。

快速链接：文档，更新日志

其他语言文档：简体中文、日本語、Español、Português、한국어、Deutsch

在 StackBlitz 中在线尝试 Vite 5.1：vanilla、vue、react、preact、lit、svelte、solid、qwik。

如果你还不熟悉 Vite，建议先阅读快速开始和功能特性指南。

要获取最新动态，请在 X 或 Mastodon 上关注我们。

Vite Runtime API

Vite 5.1 增加了对新的 Vite Runtime API 的实验性支持。该 API 允许先通过 Vite 插件处理代码，然后再运行任何代码。它与 server.ssrLoadModule 不同，因为运行时实现与服务器解耦，这样库和框架作者就可以在服务器和运行时之间实现自己的通信层。一旦该 API 稳定，它将取代 Vite 现有的 SSR 原语。

新 API 带来了诸多好处：

• 支持 SSR 期间的 HMR。
• 与服务器解耦，因此单个服务器可以服务的客户端数量没有限制——每个客户端都有自己的模块缓存（你甚至可以按照自己的方式与之通信——使用消息通道、fetch 调用、直接函数调用或 WebSocket）。
• 不依赖任何 Node/Bun/Deno 内置 API，因此可以在任何环境中运行。
• 很容易与那些拥有自己的代码运行机制的工具集成（例如，你可以提供一个 runner，使用 eval 而不是 new AsyncFunction）。

最初的想法由 Pooya Parsa 提出，并由 Anthony Fu 实现为 vite-node 包，用于为 Nuxt 3 Dev SSR 提供动力，后来也作为 Vitest 的基础。因此，vite-node 的总体思路已经经过了相当一段时间的实战检验。这是由 Vladimir Sheremet 对 API 进行的新一轮迭代，他已经在 Vitest 中重新实现了 vite-node，并将这些经验用于在加入到 Vite Core 时使 API 更加强大和灵活。这个 PR 历时一年，你可以在这里看到演化过程以及与生态系统维护者的讨论。

ℹ️ 信息
Vite Runtime API 后来演变为 Module Runner API，并作为 Environment API 的一部分在 Vite 6 中发布。

功能特性

改进对 .css?url 的支持

现在，将 CSS 文件作为 URL 导入可以可靠且正确地工作了。这是 Remix 迁移到 Vite 过程中的最后一个障碍。参见 (#15259)。

build.assetsInlineLimit 现在支持回调函数

用户现在可以提供一个回调函数，该回调返回一个布尔值，以选择是否对特定资源进行内联。如果返回 undefined，则应用默认逻辑。参见 (#15366)。

改进了循环导入的 HMR

在 Vite 5.0 中，循环导入中被接受的模块总是会触发整页重新加载，即使它们可以在客户端正常处理。现在这一行为得到了放宽，允许 HMR 在不进行整页重新加载的情况下生效；但如果 HMR 期间发生任何错误，页面仍将重新加载。参见 (#15118)。

支持 ssr.external: true 以外部化所有 SSR 包

从历史上看，Vite 会将除链接包之外的所有包外部化。这个新选项可以用来强制外部化所有包，包括链接包。这在 monorepo 中的测试中非常有用，因为在这些测试中，我们想要模拟所有包都被外部化的常见情况；或者当使用 ssrLoadModule 加载任意文件时，我们希望始终外部化包，因为我们不关心 HMR。参见 (#10939)。

在预览服务器中暴露 close 方法

预览服务器现在暴露了一个 close 方法，该方法将正确地关闭服务器，包括所有已打开的 socket 连接。参见 (#15630)。

性能改进

Vite 的每个版本都在不断变快，Vite 5.1 也包含了许多性能改进。我们使用 vite-dev-server-perf 对自 Vite 4.0 以来的所有次要版本进行了 10K 模块（25 层深度的树）加载时间的测量。这是一个很好的基准测试，用于衡量 Vite 无打包方案的效果。每个模块都是一个带有计数器的小型 TypeScript 文件，并导入树中的其他文件，因此这主要衡量的是将请求作为独立模块处理所需的时间。在 Vite 4.0 中，在 M1 MAX 上加载 10K 模块需要 8 秒。在 Vite 4.3 中，我们专注于性能，并取得了突破，加载时间缩短到了 6.35 秒。在 Vite 5.1 中，我们再次实现了性能飞跃。现在，Vite 在 5.35 秒内即可完成 10K 模块的加载。

该基准测试在 Headless Puppeteer 中运行，是很好的版本对比方式。不过，这些数据并不代表用户实际体验到的加载时间。在 Chrome 的无痕窗口中运行相同的 10K 模块时，我们得到以下结果：

10K 模块	Vite 5.0	Vite 5.1
加载时间	2892ms	2765ms
加载时间（缓存）	2778ms	2477ms
完全重新加载	2003ms	1878ms
完全重新加载（缓存）	1682ms	1604ms

在线程中运行 CSS 预处理器

Vite 现在提供了在线程中运行 CSS 预处理器的可选支持。你可以使用 css.preprocessorMaxWorkers: true 来启用它。对于一个 Vuetify 2 项目，启用该功能后，开发启动时间减少了 40%。在 PR 中还有其他配置下的性能对比。参见 (#13584)。提供反馈。

改善服务器冷启动的新选项

你可以设置 optimizeDeps.holdUntilCrawlEnd: false 来切换到一种新的依赖优化策略，这可能有助于大型项目。我们正在考虑将来默认采用这种策略。提供反馈。(#15244)

通过缓存检查加快解析速度

fs.cachedChecks 优化现在默认启用。在 Windows 上，启用它后 tryFsResolve 的速度提高了约 14 倍，并且在 triangle 基准测试中，整体 id 解析速度提高了约 5 倍。(#15704)

内部性能改进

开发服务器获得了多项增量性能提升。一个新的中间件，可在 304 时直接短路 (#15586)。我们避免了在热路径中调用 parseRequest (#15617)。Rollup 现在可以正确地懒加载了 (#15621)。

弃用与移除

我们继续尽可能地缩减 Vite 的 API 面，以便项目能够长期维护。

弃用 import.meta.glob 中的 as 选项

标准已经转向 Import Attributes，但我们目前不打算用新选项来替代 as。相反，建议用户改用 query。参见 (#14420)。

移除实验性的构建时预打包

构建时预打包（Build-time pre-bundling）是 Vite 3 中引入的一项实验性功能，现已被移除。随着 Rollup 4 将其解析器切换到原生实现，以及 Rolldown 的开发，这项功能的性能优势和开发与构建之间的不一致问题都不再成立。我们希望继续改善开发与构建的一致性，并得出结论：使用 Rolldown 来进行“开发时预打包”和“生产构建”是未来更好的选择。Rolldown 还可能在构建期间实现比依赖预打包高效得多的缓存方式。参见 (#15184)。

参与贡献

我们感谢 Vite Core 的 900 位贡献者，以及推动生态系统不断向前发展的插件、集成、工具和翻译的维护者们。如果你喜欢 Vite，我们邀请你参与并帮助我们。请查看我们的贡献指南，并参与问题分类、PR 评审，在 GitHub Discussions 上回答问题，以及在 Vite Land 中帮助社区中的其他人。

致谢

Vite 5.1 的实现离不开我们的贡献者社区、生态系统维护者以及 Vite 团队。特别感谢赞助 Vite 开发的个人和公司。StackBlitz、Nuxt Labs 和 Astro 雇佣了 Vite 团队成员。也感谢 Vite 的 GitHub Sponsors、Vite 的 Open Collective 和 Evan You 的 GitHub Sponsors 上的赞助者。