从 Vite 5 到 Vite 6:全面升级指南
随着 Vite 6 的发布,这款现代化的构建工具再一次为前端开发者带来了新的性能优化和功能增强。在保留快速构建体验的基础上,Vite 6 引入了实验性的环境 API、改进的模块解析逻辑以及更强大的 CSS 和 JSON 处理功能。同时,这次升级也伴随着一些破坏性变更,需要开发者进行适当的调整。
本文将深入解析 Vite 6 的重要变化和迁移步骤,帮助你轻松完成从 Vite 5 到 Vite 6 的过渡。 Vite 6是自 Vite 2以来最重要的主要版本。我们渴望与生态系统合作,通过新的 API 不断扩展我们的共享共享空间,并且像往常一样,建立一个更加完善的基础。
快速开始使用 Vite 6
您可以使用 pnpm create Vite 来快速构建带有您首选框架的 Vite 应用程序,或者使用 Vite.new 在线使用 Vite 6。您还可以运行pnpm create vite-extra 来访问其他框架和运行时(Solid、 Deno、 SSR 和库启动程序)中的模板。当在“其他”选项下运行 create vite 时,也可以使用 create vite-extra 模板。
Node.js 支持
Vite 6支持 Node.js 18、20和22 + ,类似于 Vite 5。已经放弃了对 Node.js 21的支持。Vite 在 EOL 之后放弃了对旧版本 Node.js 的支持。Node.js 18 EOL 将于2025年4月底发布,之后我们可能会发布一个新的专业版本来提升所需的 Node.js 版本。
实验环境 API(Experimental Environment API
Vite 使用新的 Environment API 变得更加灵活。这些新的 API 将允许框架作者提供更接近生产的开发体验,并允许 Ecossystem 共享新的构建块。如果您正在构建 SPA,那么什么都不会改变; 当您在单个客户端环境中使用 Vite 时,一切都和以前一样。甚至对于定制的 SSR 应用程序,Vite 6也是向后兼容的。Environment API 的主要目标受众是框架作者。 对于感兴趣的终端用户来说,Sapphi 撰写了一篇很棒的《环境 API 入门指南》。这是一个很好的起点,可以帮助你理解我们为什么要努力让 Vite 更加灵活。 如果您是一个框架作者或 Vite 插件维护者,并且希望利用新的 API,那么您可以在 Environment API Guides 中了解更多信息。
Vite Runtime API
实验性的 Vite Runtime API 已经演变为模块运行器 API(Module Runner API),这是作为新的实验性 环境 API 的一部分,在 Vite 6 中发布。鉴于这个功能是实验性的,所以在 Vite 5.1 中引入的先前 API 的移除并不是一个破坏性的更改,但是用户在迁移到 Vite 6 的过程中,需要将他们的使用方式更新为与模块运行器相等的方式。
主要变化
resolve.conditions 的默认值
此更改不会影响未配置 resolve.conditions / ssr.resolve.conditions / ssr.resolve.externalConditions 的用户。
在 Vite 5 中,resolve.conditions 的默认值是 [],某些条件是内部添加的。ssr.resolve.conditions 的默认值是 resolve.conditions 的值。
从 Vite 6 开始,部分条件不再在内部添加,需要包含在配置值中。 不再在内部添加的条件为
resolve.conditions是['module', 'browser', 'development|production']ssr.resolve.conditions是['module', 'node', 'development|production']
这些选项的默认值会更新为相应的值,ssr.resolve.conditions 不再使用 resolve.conditions 作为默认值。请注意,development|production是一个特殊变量,会根据 process.env.NODE_ENV 的值被替换为 production 或 development。这些默认值从 vite 导出为 defaultClientConditions 和 defaultServerConditions。
如果为 resolve.conditions 或 ssr.resolve.conditions 指定了自定义值,则需要更新该值以包含新条件。 例如,如果先前为 resolve.conditions 指定了 ['custom'],那么现在就需要指定 ['custom', ...defaultClientConditions]。
JSON stringify
在 Vite 5 中,当设置 json.stringify: true 时,json.namedExports 会被禁用。
从 Vite 6 开始,即使设置了 json.stringify: true,json.namedExports 也不会被禁用。如果希望实现以前的行为,可以设置 json.namedExports: false。
Vite 6 还为 json.stringify 引入了一个新的默认值,即 'auto',它只会对大型 JSON 文件进行字符串化处理。要禁用此行为,请设置 json.stringify: false。
在 HTML 元素中扩展对资源引用的支持
在 Vite 5 中,只有少数支持的 HTML 元素能够引用由 Vite 处理和打包的资源,如<link href>、<img src> 等。
Vite 6 扩展了对更多 HTML 元素的支持。完整列表请参见 HTML 功能介绍 文档。
要在某些元素上选择不进行 HTML 处理,可以在元素上添加 vite-ignore 属性。
postcss-load-config
postcss-load-config 已从 v4 更新至 v6。现在需要 tsx 或 jiti 来加载 TypeScript postcss 配置文件,而非 ts-node。此外,现在需要 yaml 来加载 YAML postcss 配置文件。
Sass 现在默认使用现代 API
在 Vite 5 中,Sass 默认使用传统 API。Vite 5.4 增加了对现代 API 的支持。
从 Vite 6 开始,Sass 默认使用现代 API。如果想继续使用传统 API,可以设置 css.preprocessorOptions.sass.api: 'legacy' / css.preprocessorOptions.scss.api: 'legacy'。但请注意,传统 API 支持将在 Vite 7 中移除。
要迁移到现代 API,请参阅 Sass 文档。
在 library 模式下自定义 CSS 输出文件名
在 Vite 5 中,library 模式下的 CSS 输出文件名始终是 style.css,无法通过 Vite 配置轻松更改。
从 Vite 6 开始,默认文件名将使用 package.json 中的 "name",与 JS 输出文件类似。如果 build.lib.fileName 设置为字符串,该值也将用于 CSS 输出文件名。要明确设置不同的 CSS 文件名,可以使用新的 build.lib.cssFileName 进行配置。
迁移时,如果您依赖于 style.css 文件名,则应根据软件包名称将对该文件的引用更新为新名称。例如:
{
"name": "my-lib",
"exports": {
- "./style.css": "./dist/style.css"
+ "./style.css": "./dist/my-lib.css"
}
}
如果你更喜欢像在 Vite 5 中那样使用 style.css,可以设置 build.lib.cssFileName: 'style'。
进阶
还有其他一些只影响少数用户的破坏性更改。
-
[#17922] fix(css)!: remove default import in ssr dev
- 对 CSS 文件默认导入的支持在 Vite 4 中已被弃用,并在 Vite 5 中被移除,但在 SSR 开发模式中仍被无意支持。现在该支持已被移除。
-
[#15637] fix!: default
build.cssMinifyto'esbuild'for SSRbuild.cssMinify现在即使是 SSR 版本也默认为启用。
-
[#18070] feat!: proxy bypass with WebSocket
server.proxy[path].bypass现在用于 WebSocket 升级请求,在这种情况下,res参数将是undefined。
-
[#18209] refactor!: bump minimal terser version to 5.16.0
build.minify: 'terser'所支持的最小 terser 版本从 5.4.0 提升至 5.16.0
-
[#18231] chore(deps): update dependency @rollup/plugin-commonjs to v28
-
commonjsOptions.strictRequires现在默认为true(之前为'auto')。- 这可能会导致包的大小增大,但会使构建更加确定。
- 如果将 CommonJS 文件指定为入口点,则可能需要额外的步骤。阅读 commonjs plugin 文档 了解更多详情.
-
-
[#18243] chore(deps)!: migrate
fast-globtotinyglobby- globs 中不再支持范围大括号 (
{01..03}⇒['01', '02', '03']) 和递增大括号 ({2..8..2}⇒['2', '4', '6', '8']) 。
- globs 中不再支持范围大括号 (
-
[#18395] feat(resolve)!: allow removing conditions
- 此 PR 不仅引入了上文提到的 "
resolve.conditions的默认值" 这一破坏性变更,还使得在 SSR 中,resolve.mainFields不能用于无外部化依赖关系。如果您正在使用resolve.mainFields,并希望将其应用于 SSR 中的无外部化依赖关系,您可以使用ssr.resolve.mainFields。
- 此 PR 不仅引入了上文提到的 "
-
[#18493] refactor!: remove fs.cachedChecks option
- 由于在缓存文件夹中写入文件并立即导入时会出现边缘情况,因此删除了这一选择优化。
-
[#18697] fix(deps)!: update dependency dotenv-expand to v12
- 插值中使用的变量应在插值之前声明。更多详情,请参阅
dotenv-expandchangelog。
- 插值中使用的变量应在插值之前声明。更多详情,请参阅
-
[#16471] feat: v6 - Environment API
- 对仅 SSR 模块的更新不再触发客户端的页面重载。要恢复以前的行为,可使用自定义 Vite 插件: 示例:
import type { Plugin, EnvironmentModuleNode } from 'vite'
function hmrReload(): Plugin {
return {
name: 'hmr-reload',
enforce: 'post',
hotUpdate: {
order: 'post',
handler({ modules, server, timestamp }) {
if (this.environment.name !== 'ssr') return
let hasSsrOnlyModules = false
const invalidatedModules = new Set<EnvironmentModuleNode>()
for (const mod of modules) {
if (mod.id == null) continue
const clientModule =
server.environments.client.moduleGraph.getModuleById(mod.id)
if (clientModule != null) continue
this.environment.moduleGraph.invalidateModule(
mod,
invalidatedModules,
timestamp,
true,
)
hasSsrOnlyModules = true
}
if (hasSsrOnlyModules) {
server.ws.send({ type: 'full-reload' })
return []
}
},
},
}
}
参考资料:
以下是 Vite 官方与社区提供的相关资源,可供深入了解 Vite 6 的更新内容:
- Vite 官方博客发布公告
vite.dev/blog/announ… - Vite GitHub 仓库 - Changelog
github.com/vitejs/vite… - Environment API 入门指南
green.sapphi.red/blog/increa… - Environment API 指南 - 官方文档
main.vite.dev/guide/api-e…