Vite 5.1 发布了！
2024年2月8日
Vite 5 于去年11月发布，它代表了 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。
要了解最新动态，请在 X 或 Mastodon 上关注我们。
Vite Runtime API
Vite 5.1 为全新的 Vite Runtime API 增加了实验性支持。它允许通过先用 Vite 插件处理代码来运行任何代码。它与 server.ssrLoadModule 不同，因为运行时实现与服务器解耦了。这使得库和框架作者能够实现自己的服务器和运行时之间的通信层。这个新 API 旨在在稳定后取代 Vite 当前的 SSR 原语。
新 API 带来了许多好处
- 支持在 SSR 期间进行热更新（HMR）。
- 它与服务器解耦，因此不受单个服务器连接客户端数量的限制——每个客户端都有自己的模块缓存（您甚至可以使用您想要的任何方式与之通信——使用消息通道、fetch 调用、直接函数调用或 websocket）。
- 它不依赖于任何 Node/Bun/Deno 的内置 API，因此可以在任何环境中运行。
- 它很容易与拥有自己代码运行机制的工具集成（例如，您可以提供一个运行器来使用
eval而不是new AsyncFunction）。
最初的构想由 Pooya Parsa 提出，并由 Anthony Fu 作为 vite-node 包实现，用于驱动 Nuxt 3 开发环境下的 SSR，后来也成为了 Vitest 的基础。因此，vite-node 的总体构想已经经过了相当长时间的实战检验。这是由 Vladimir Sheremet 对该 API 进行的全新迭代，他已经在 Vitest 中重新实现了 vite-node，并汲取了经验，使 API 在加入 Vite Core 时变得更加强大和灵活。该 PR 开发历时一年，您可以在这里查看其演变过程以及与生态系统维护者的讨论。
信息
Vite Runtime API 演变成了 Module Runner API，在 Vite 6 中作为环境 API（Environment API）的一部分发布。
功能
改进对 .css?url 的支持
现在，将 CSS 文件作为 URL 导入可以稳定且正确地工作。这是 Remix 迁移到 Vite 的最后一个障碍。见 (#15259)。
build.assetsInlineLimit 现在支持回调函数
用户现在可以提供一个回调函数，返回布尔值来选择开启或关闭特定资源的内联。如果返回 undefined，则应用默认逻辑。见 (#15366)。
改进循环导入的热更新（HMR）
在 Vite 5.0 中，循环导入中被接受的模块即使在客户端可以正常处理，也会触发全页面重载。现在这一限制已放宽，允许在不进行全页面重载的情况下应用 HMR，但如果 HMR 期间发生任何错误，页面仍将重新加载。见 (#15118)。
支持 ssr.external: true 以将所有 SSR 包外部化
历史上，Vite 会外部化除链接包（linked packages）之外的所有包。此新选项可用于强制外部化所有包，包括链接包。这在 monorepo 的测试中非常有用，因为我们希望模拟所有包都被外部化的通常情况；或者在使用 ssrLoadModule 加载任意文件时，我们希望始终外部化包，因为我们不关心 HMR。见 (#10939)。
预览服务器中公开 close 方法
预览服务器现在公开了一个 close 方法，它将正确关闭服务器，包括所有打开的套接字连接。见 (#15630)。
性能提升
Vite 在每个版本中都在不断变快，Vite 5.1 包含了多项性能改进。我们使用 vite-dev-server-perf 测量了从 Vite 4.0 开始的所有次要版本的 10K 模块（25 层深树）的加载时间。这是衡量 Vite 无打包（bundle-less）方法效果的一个很好的基准。每个模块都是一个包含计数器和对树中其他文件导入的小型 TypeScript 文件，因此这主要衡量的是作为独立模块进行请求所需的时间。在 Vite 4.0 中，在 M1 MAX 上加载 10K 模块耗时 8 秒。在 Vite 4.3 中我们专注于性能并取得了突破，我们将加载时间缩短到了 6.35 秒。而在 Vite 5.1 中，我们又实现了一次性能飞跃。Vite 现在仅需 5.35 秒即可提供 10K 模块。
此基准测试的结果是在无头 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 倍，并且在三角形基准测试中，总体 ID 解析速度提升了约 5 倍。 (#15704)
内部性能改进
开发服务器进行了几项增量性能提升。增加了用于 304 短路的新中间件 (#15586)。我们在热点路径中避免了 parseRequest (#15617)。Rollup 现在可以正确进行懒加载 (#15621)。
弃用
我们继续尽可能减少 Vite 的 API 面，以确保项目的长期可维护性。
弃用 import.meta.glob 中的 as 选项
标准已经转向 导入属性 (Import Attributes)，但我们目前不打算用新选项替换 as。建议用户改用 query。见 (#14420)。
移除实验性的构建时预打包
Vite 3 中添加的实验性功能“构建时预打包”已被移除。随着 Rollup 4 将其解析器切换为原生代码，以及 Rolldown 的开发，该功能的性能优势和开发与构建不一致的问题已不再存在。我们希望继续改善开发/构建的一致性，并得出结论：使用 Rolldown 进行“开发时预打包”和“生产环境构建”是未来的更好选择。Rolldown 在构建时可能还会以比依赖预打包效率高得多的方式实现缓存。见 (#15184)。
参与其中
我们衷心感谢 900 位 Vite Core 贡献者，以及插件、集成、工具和翻译的维护者，他们不断推动生态系统向前发展。如果您喜欢 Vite，欢迎参与并帮助我们。查看我们的 贡献指南，投入到 分类 Issue、审查 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 上资助的朋友们。