Vite 5.1 发布！
2024 年 2 月 8 日
Vite 5 发布 于去年 11 月，它代表了 Vite 和生态系统的一次重大飞跃。几周前，我们庆祝了每周 1000 万次 npm 下载量和 Vite 仓库的 900 位贡献者。今天，我们很高兴地宣布 Vite 5.1 的发布。
其他语言的文档：简体中文，日本語，Español，Português，한국어，Deutsch
在 StackBlitz 中在线尝试 Vite 5.1：vanilla，vue，react，preact，lit，svelte，solid，qwik.
如果您是 Vite 的新手，我们建议您先阅读 入门 和 功能 指南。
Vite 运行时 API
Vite 5.1 添加了对新的 Vite 运行时 API 的实验性支持。它允许通过先使用 Vite 插件处理代码来运行任何代码。它与 server.ssrLoadModule 不同，因为运行时实现与服务器分离。这使库和框架作者能够实现他们自己的服务器和运行时之间的通信层。这个新的 API 旨在取代 Vite 的当前 SSR 原语，一旦它稳定下来。
新的 API 带来了许多好处
- 支持 SSR 期间的 HMR。
- 它与服务器分离，因此对单个服务器可以使用多少个客户端没有限制 - 每个客户端都有自己的模块缓存（您甚至可以根据自己的意愿与它通信 - 使用消息通道/获取调用/直接函数调用/websocket）。
- 它不依赖于任何 node/bun/deno 内置 API，因此它可以在任何环境中运行。
- 它易于与具有自己的代码运行机制的工具集成（例如，您可以提供一个运行器来使用
eval而不是new AsyncFunction）。
最初的想法 是由 Pooya Parsa 提出的，并由 Anthony Fu 作为 vite-node 包来 为 Nuxt 3 Dev SSR 提供支持，后来也用作 Vitest 的基础。因此，vite-node 的总体思路已经过相当长一段时间的实战检验。这是由 Vladimir Sheremet 对 API 的全新迭代，他之前已经在 Vitest 中重新实现了 vite-node，并将经验教训应用于在将 API 添加到 Vite Core 时使其更加强大和灵活。这个 PR 已经酝酿了一年，您可以在这里看到与生态系统维护者的演变和讨论 这里。
在 Vite 运行时 API 指南 中了解更多信息，并 给我们反馈。
功能
改进对 .css?url 的支持
将 CSS 文件作为 URL 导入现在可以可靠且正确地工作。这是 Remix 迁移到 Vite 的最后一个障碍。参见 (#15259).
build.assetsInlineLimit 现在支持回调
用户现在可以 提供一个回调，该回调返回一个布尔值来选择加入或选择退出特定资产的内联。如果返回 undefined，则应用默认逻辑。参见 (#15366).
改进循环导入的 HMR
在 Vite 5.0 中，循环导入中的接受模块始终触发完整的页面重新加载，即使它们可以在客户端正常处理。现在放宽了限制，允许 HMR 在不进行完整页面重新加载的情况下应用，但如果 HMR 期间发生任何错误，页面将重新加载。参见 (#15118).
支持 ssr.external: true 来外部化所有 SSR 包
从历史上看，Vite 会外部化所有包，除了链接的包。这个新的选项可以用来强制外部化所有包，包括链接的包。这在单仓库中的测试中非常有用，我们希望模拟所有包都被外部化的常见情况，或者在使用 ssrLoadModule 加载任意文件时，我们希望始终外部化包，因为我们不关心 HMR。参见 (#10939).
在预览服务器中公开 close 方法
预览服务器现在公开了一个 close 方法，它将正确地拆除服务器，包括所有打开的套接字连接。参见 (#15630).
性能改进
Vite 每次发布都变得更快，Vite 5.1 充满了性能改进。我们使用 vite-dev-server-perf 测量了从 Vite 4.0 开始的所有次要版本的 10K 个模块（25 级深层树）的加载时间。这是一个很好的基准，可以衡量 Vite 无捆绑方法的效果。每个模块都是一个带有计数器的小型 TypeScript 文件，并导入树中的其他文件，因此这主要测量了执行单独模块请求所需的时间。在 Vite 4.0 中，加载 10K 个模块在 M1 MAX 上需要 8 秒。我们在 Vite 4.3 中专注于性能，并能够在 6.35 秒内加载它们。在 Vite 5.1 中，我们设法实现了另一个性能飞跃。Vite 现在可以在 5.35 秒内提供 10K 个模块。
此基准测试在 Headless Puppeteer 上运行的结果是比较版本的好方法。但是，它们并不代表用户体验的时间。当在 Chrome 的隐身窗口中运行相同的 10K 个模块时，我们有
| 10K 个模块 | Vite 5.0 | Vite 5.1 |
|---|---|---|
| 加载时间 | 2892 毫秒 | 2765 毫秒 |
| 加载时间（已缓存） | 2778 毫秒 | 2477 毫秒 |
| 完全重新加载 | 2003 毫秒 | 1878 毫秒 |
| 完全重新加载（已缓存） | 1682 毫秒 | 1604 毫秒 |
在线程中运行 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 选项
标准已迁移至 导入属性，但我们目前不打算用新选项替换 as。建议用户切换到 query。请参见 (#14420).
移除实验性的构建时预打包
构建时预打包是 Vite 3 中添加的实验性功能，现已移除。随着 Rollup 4 将其解析器切换到原生解析器，以及 Rolldown 的开发，此功能的性能和开发与构建不一致问题不再有效。我们希望继续改进开发/构建一致性，并得出结论，使用 Rolldown 进行“开发期间预打包”和“生产构建”是未来更好的选择。Rolldown 也可能以比依赖项预打包更有效的方式实现构建期间的缓存。请参见 (#15184).
参与进来
我们感谢 900 位 Vite 核心贡献者，以及插件、集成、工具和翻译的维护者，他们不断推动生态系统向前发展。如果您喜欢 Vite，我们邀请您参与并帮助我们。查看我们的 贡献指南，并加入 问题分类、审查 PR、在 GitHub 讨论 中回答问题，并在 Vite Land 中帮助社区中的其他人。
致谢
Vite 5.1 的发布要感谢我们的贡献者社区、生态系统中的维护者以及 Vite 团队。向为 Vite 开发提供赞助的个人和公司致敬。 StackBlitz、Nuxt Labs 和 Astro 聘用了 Vite 团队成员。还要感谢 Vite 的 GitHub 赞助商、Vite 的 Open Collective 和 Evan You 的 GitHub 赞助商。