Vite 3.0 发布!
2022 年 7 月 23 日 - 查看 Vite 4.0 公告
去年 2 月,尤雨溪 发布了 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 版本或参与核心开发时非常有用。
现在还有一个官方的西班牙语翻译,它被添加到之前的中文和日语翻译中。
创建 Vite 启动模板
create-vite 模板一直是使用您最喜欢的框架快速测试 Vite 的绝佳工具。在 Vite 3 中,所有模板都采用了与新文档一致的新主题。立即在线打开它们并开始使用 Vite 3。
该主题现在由所有模板共享。这有助于更好地传达这些启动模板作为使用 Vite 入门的最小模板的范围。对于更完整的解决方案(包括 lint、测试设置和其他功能),一些框架(如 create-vue 和 create-svelte)提供了官方的 Vite 支持模板。在 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 能够在 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' } })
急切导入 现在作为标志传递
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 外部化启发式方法,默认情况下外部化依赖项。
改进的相对基路径支持
Vite 3 现在正确支持相对基路径(使用base: ''
),允许构建的资产部署到不同的基路径而无需重新构建。这在构建时未知基路径时非常有用,例如部署到诸如 IPFS 之类的内容寻址网络时。
实验性功能
构建资产路径细粒度控制(实验性)
还有其他部署场景,在这种场景下,这还不够。例如,如果生成的哈希资产需要部署到与公共文件不同的 CDN,则需要在构建时对路径生成进行更细粒度的控制。Vite 3 提供了一个实验性 API 来修改构建的文件路径。有关更多信息,请查看 构建高级基路径选项。
构建时 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。您可以在 此提案的讨论 中了解更多信息。
包体积缩减
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 移出单仓,并实现了一个新的插件来支持自动生成 https 证书:@vitejs/plugin-basic-ssl
。由于此功能仅创建未经信任的证书,并且不会添加到本地存储中,因此它不值得增加大小。
错误修复
由最近加入 Vite 团队的 @bluwyoo 和 @sapphi_red 发起了错误分类马拉松。在过去的三个月中,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 核心 的贡献体验。
- 单元测试和端到端测试已迁移到 Vitest,提供了更快、更稳定的开发者体验。此举也为生态系统中的一个重要基础设施项目进行了内部测试。
- VitePress 构建现在作为 CI 的一部分进行测试。
- Vite 升级到 pnpm 7,跟随生态系统其余部分的步伐。
- 游乐场已从 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 的开发者体验。