Vite CHANGELOG 详解从 6.0 到 8.2.2 的版本演进、生成机制与升级实操指南【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vitepackages/vite/CHANGELOG.md 是 Vite 核心包的官方版本变更记录完整记录了 Vite 6.0.02024-11-26至今每一个发布版本的 Feature、Bug Fix、破坏性变更与内部重构共约 2400 行。本文基于该文档及其配套的发布脚本scripts/prepare-release.ts、scripts/extract-changelog.ts进行解读先讲清楚 Changelog 的格式规范与阅读方法再梳理 6.0 / 7.0 / 8.0 三个大版本与 8.x 系列的关键演进节点最后说明它如何由发布流水线自动生成帮助你在升级 Vite 前快速、准确地判断风险与收益。一、Changelog 的格式规范如何看懂每一个版本条目版本头部的写法文档中每个版本以二级标题开头格式为## 版本号 (发布日期)。其中v8.2.1...v8.2.2这样的 compare 链接标明该版本相对上一版本包含了哪些提交。值得注意的是标题是否包在small标签内隐含了版本语义小版本patch用small包裹表示向后兼容的修订。例如文档第一行 8.2.2 条目## small8.2.2 (2026-08-20)/small次版本minor与大版本major不加small例如 8.2.0、8.1.0、8.0.0通常意味着包含新 Feature 或破坏性变更beta 版本按 minor 标题处理如 8.2.0-beta.0但不会作为正式稳定版被广泛引用。条目分节的固定结构每个版本内部按固定小节组织顺序大致为BREAKING CHANGES仅大版本→Features→Bug Fixes→Performance Improvements→Documentation→Miscellaneous Chores→Code Refactoring→Tests→Build System→Continuous Integration。并非每个版本都有全部小节patch 版本往往只有Bug Fixes。例如 8.2.2 就包含了 Features、Bug Fixes、Documentation、Miscellaneous Chores、Code Refactoring、Tests、Build System 七个小节而 8.1.2 仅有 4 条 Bug Fixes。单条记录的三段式信息每条记录都是* **scope:** 变更描述 (#PR 号) (commit 短哈希)的结构。以 8.2.2 中的一条为例CHANGELOG 第 11 行* **css:** dont pass empty targets to lightningcss (#23295) (2804636)三个信息位各有用途scope加粗前缀标识受影响的子系统高频出现的 scope 包括css、optimizer/optimize-deps、server/dev、ssr、build、hmr、module-runner、bundled-dev、resolve、html、worker、wasm、glob、config、deps等。没有 scope 前缀的条目如reduce Windows 8.3-short-name detection false-positives表示影响范围较广的核心行为修复PR 号是理解变更细节的最佳入口——每条记录都对应一个可追溯的 Pull Request从 scope 和描述可以定位到具体 issue/PR 讨论commit 哈希用于在 git 历史中直接定位提交。**deps:**前缀的条目是依赖升级记录例如 8.2.2 中的update rolldown-related dependencies (#23218)这类条目在几乎每个版本中都会出现说明 Vite 与 Rolldown 等核心依赖保持高频同步。二、当前版本与运行环境要求packages/vite/package.json 中的version字段为8.2.2与 Changelog 顶部条目一致即当前仓库快照对应的最新稳定版。运行环境要求可以从 package.json 的 engines 字段 确认engines: { node: ^20.19.0 || 22.12.0 }即Node.js 20.19 或 22.12。这一要求始于 7.0.0——7.0.0 的 BREAKING CHANGES 中明确列有bump required node version to 20.19, 22.12 and remove cjs build (#20032)意味着从 Vite 7 开始包只以 ESM 形式分发不再提供 CJS 构建低版本 Node 用户升级 7.x/8.x 前必须先升级 Node。三、三大里程碑版本6.0、7.0、8.0Changelog 中三个大版本条目都附有发布公告、文档与迁移指南的入口正文信息量远大于 patch 版本是升级判断的核心依据。Vite 6.0.02024-11-26Environments API 登场6.0.0 条目 是文档中信息密度最高的大版本之一核心是Environment APIEnvironment API (#16471)这是 Vite 6 的主打特性将 dev/SSR/lib 等场景统一抽象为 Environment围绕它衍生出一批相关变更introduce RunnableDevEnvironment (#18190)、add environment::listen (#18263)、expose EnvironmentOptions type (#18080)SSR 侧能力增强enable dependencies discovery and pre-bundling in ssr environments (#18358)、add ssr.resolve.mainFields option (#18646)模块获取统一use a single transport for fetchModule and HMR support (#18362)ModuleRunner 侧enable HMR by default on ModuleRunner side (#18749)。其他值得注意的 6.0 变更均见 6.0.0 Features/Breaking 小节asset: add ?inline and ?no-inline queries to control inlining (#15454)——资产内联从此有了显式控制开关json: add json.stringify: auto and make that the default (#18303)css: change default sass api to modern/modern-compiler (#17937)update to chokidar v4 (#18453)、proxy bypass with WebSocket (#18070)、html: support vite-ignore attribute to opt-out of processing (#18494)破坏性变更还包括remove fs.cachedChecks option (#18493)、drop node 21 support in version ranges (#18729)。Vite 7.0.02025-06-24环境收紧与构建体系切换7.0.0 条目 的 BREAKING CHANGES 小节集中体现了这一版做减法的主题破坏性变更PR影响Node 版本要求提升到 20.19/22.12移除 CJS 构建#20032低版本 Node 与 CJS 消费方受影响build.target提升并命名为baseline-widely-available#20007默认产物语法基线上移CSS 始终使用 sass compiler API、移除 sass legacy API#19978 / #19977老式 sass 配置需迁移移除splitVendorChunkPlugin#19255使用manualChunks替代移除HotBroadcaster及相关类型#19988 / #19987插件需改用新 HMR 广播机制移除experimental.skipSsrTransform#20038SSR 转换不再可整体跳过Feature 方面7.0 引入了插件系统的重要扩展见 7.0.0 Features 小节buildApp hook (#19971)、this.meta.viteVersion (#20088)、import.meta.glob的base选项#20163、PluginContext available for Vite-specific hooks (#19936)并将css.preprocessorMaxWorkers与optimizeDeps.noDiscovery两个实验项正式稳定化。Vite 8.0.02026-03-12Rolldown 合并Vite 2 以来最大架构变更8.0.0 条目 是整份 Changelog 的分水岭其 BREAKING CHANGES 小节只有三条但分量极重⚠ BREAKING CHANGES * remove import.meta.hot.accept resolution fallback (#21382) * update default browser target (#21193) * the epic rolldown-vite merge (#21189)其中the epic rolldown-vite merge标志着Rolldown 成为 Vite 唯一的打包器取代了此前esbuild 负责开发、Rollup 负责生产的双打包器架构。仓库内的 Vite 8 发布公告 对这一变更有完整阐述Rolldown 是 Rust 编写、兼容 Rollup 插件 API 的打包器迁移先以独立的rolldown-vite包进行技术预览经社区真实项目验证后才在 8.0 稳定版中合并公告称之为自 Vite 2 以来最重要的架构变更并列出了 Linear、Ramp、Mercedes-Benz.io、Beehiiv 等团队在生产构建中观察到的构建时长下降。8.0.0 的 Features 小节L643-L681同样密集可归纳为几个方向打包器与插件体系the epic rolldown-vite merge (#21189)、introduce v2 native plugins and enable it by default (#21268)、highly experimental full bundle mode (#21235)全量打包开发模式后续在 8.0.x 中以bundled-dev名义持续演进Rolldown 版本推进条目中密集出现update rolldown to 1.0.0-beta.x / rc.x的记录直至 8.0.0 稳定版锁定1.0.0-rc.9可见 8.0 的开发周期2025-12 至 2026-03与 Rolldown 1.0 的定型过程完全同步开发者体验integrate devtools (#21331)Vite Devtools 集成、forward browser console logs and errors to dev server terminal (#20916)浏览器控制台转发到终端便于 Agent 协作场景、shortcuts case insensitive (#21224)Wasm 与 CSSwasm: add SSR support for .wasm?init (#21102)、css: support es2024/es2025 build target for lightningcss (#21294/#21769)、stylus Evaluator support (#21376)构建输出manifest: add assets field for standalone CSS entry points (#21015)、add ignoreOutdatedRequests option to optimizeDeps (#21364)。此外8.0.0 之后还有大量8.0.x的 patch 版本8.0.1 到 8.0.16持续将 Rolldown 从 rc.10 推进到 1.0.3 并修复环境级配置合并rolldownOptions/rollupOptions merging at environment level (#21612)、isBundled按环境区分等问题——这一连串 patch 是 Rolldown 合并后稳定化工作的直接证据。四、8.1 与 8.2 系列稳定版之后的持续演进8.1.02026-06-23与 8.1.0-beta.02026-06-158.1.0-beta.0 条目 是 8.x 系列中 Feature 最丰富的一次主要包括构建build: chunk importmap (#21580)——构建产物引入 chunk 级 import map 机制8.0.x 中已有大量相关的chunkImportMap修复铺垫如 8.0.12 的 worker 相关修复开发wasm: direct .wasm imports (WASM ESM Integration) (#21779)——.wasm 可直接以 ESM 方式导入integrate with Vite Task for zero-config build caching (#22453)——零配置构建缓存配置rename server.hmr options to server.ws options (#21357)HMR 的 WebSocket 选项更名为server.ws、import.meta.glob support caseSensitive option (#21707)、html: add html.additionalAssetSources option (#21412)CSScss: support lightningcss plugin dependency (#21748)、css: support external CSS with lightningcss (#18389)依赖优化use node_modules/.vite as cacheDir when node_modules exists (#21777)明确缓存目录默认落点。8.1.0 正式版L254-L278在此基础上主要做安全与稳定性收尾如extend server.fs.deny list with common files (#22707)、update rolldown to 1.1.2 (#22695)。其后的 8.1.4、8.1.5 等 patch 中出现了值得注意的性能与工程条目8.1.1 中css: resolve tsconfig paths in CSS and Sass import (#22775)使 tsconfig 路径别名可用于 CSSimport8.1.4 中legacy: prefer oxc as minifier (#22468)表明vitejs/plugin-legacy的压缩器也切换到了 Oxc。8.2.02026-07-30至 8.2.22026-08-20当前最新8.2.0-beta.0 的亮点是顶层input选项add input option (#22642)input提升为顶层配置后续配套了support resolving top-level input option with plugins (#23101)8.2.0 正式版与dont mutate the user config when resolving the lib entry from the top-level input (#23135)8.2.1等修复add input to server.fs.allow (#23035)server.fs.allow自动纳入input路径依赖优化器生态optimizer: support aube lockfile (#22813)与support nub lockfile (#22891)——依赖扫描器开始支持更多包管理器的 lockfile 格式此前 7.2.0 已支持 rush lockfile见 7.2.0-beta.0 条目bundled-dev 持续成熟update rolldown-related dependencies and use client-side HMR in bundled-dev (#22961)配合 8.0.13 首次加入的bundled-dev: add lazy bundling support (#21406)L378-L397全量打包开发模式的 HMR 与懒编译能力在 8.2 中逐步完善。8.2.0 正式版L81-L107还包含bundled-dev: support worker file update accepted by HMR (#23068)、config: include column in config incompatibility location (#23064)等8.2.1L46-L80修复了client chunkImportMap work with sharedPlugins: true、server: use a random port when port is 0等问题并有一项性能改进css: look up pure CSS chunks through a Set (#23114)。最新的 8.2.2 则是纯稳定化版本唯一 Feature 为widen vitejs/devtools peer range to v0.5.0 (#23302)Bug Fixes 集中在 bundled-dev循环导入改为热更新而非整页刷新#23259、module-runner在途循环检测排除已完成模块#23009、resolvepreserveSymlinks生效于 root 解析#23198、define对$前缀键的正则转义匹配#23249等细节。五、Beta 版本归档与历史版本入口Changelog 对 beta 版本采用外链归档而非全文内联8.0.0 条目末尾的 Beta Changelogs 小节 逐条列出 8.0.0-beta.02025-12-03至 beta.182026-03-09的日期并指引到对应 git tag 上的 CHANGELOG 快照7.0.0 的 Beta Changelogs 同理。文末还有 Previous Changelogs 小节将 5.4.x 到 2.0.x 的每个系列按 tag 归档如5.4.11、4.5.0、3.2.6并标注了各系列的起止日期。这意味着稳定版的完整记录在本文件中beta 与 5.x 及更早版本的历史则通过 git tag 固定文件本身保持可维护的体量。六、Changelog 如何自动生成仓库发布脚本解读这份 Changelog 不是手写维护的而是由发布流水线基于 conventional commits 自动生成。仓库中的三个脚本揭示了完整链路1. releaseUtils.ts发布对象与模板版本同步scripts/releaseUtils.ts 定义了参与发布的三个包export const releasePackages [vite, create-vite, plugin-legacy] as const同文件的updateTemplateVersions()L6-L23会在发布create-vite时读取 packages/vite/package.json 的版本号把它写入packages/create-vite/template-*/package.json的devDependencies.vite形如^8.2.2并明确跳过 beta/alpha/rc 版本——这解释了为什么 Changelog 中的正式版发布常伴随模板依赖的版本对齐。2. prepare-release.ts生成 Changelog 与发布 PRscripts/prepare-release.ts 在 CI 中运行核心调用来自vitejs/release-scriptsconst { tag, version } await prepareRelease({ packages: releasePackages, pkg, release: process.argv[3], toTag: (pkg, version) getReleaseTag(pkg, version, vite), generateChangelog: async (pkg) { if (pkg create-vite) await updateTemplateVersions() await generateChangelog({ getPkgDir: () packages/${pkg}, tagPrefix: pkg vite ? undefined : ${pkg}, }) }, })两个细节值得注意tag 命名规则vite 主包直接用vite前缀生成 tag如v8.2.2与 Changelog 标题中的 compare 链接v8.2.1...v8.2.2完全吻合而create-vite、plugin-legacy则带create-vite/plugin-legacy前缀——这是多包 monorepo 中 tag 隔离的常见做法PR 正文嵌入 Changelog脚本随后用extractChangelogEntry({ changelogPath: packages/${pkg}/CHANGELOG.md, version })抽取刚生成的版本小节拼成## Changelog段落在带__VITE_RELEASE_PR_BODY_EOF__分隔符的输出中L35-L50供 Prepare Release workflow 创建发布 PR 时直接使用。脚本还强制要求GITHUB_SERVER_URL、GITHUB_REPOSITORY、GITHUB_RUN_ID三个环境变量L15-L18并会在 PR 描述中附上本次 Actions 运行链接。3. extract-changelog.ts按版本号抽取小节scripts/extract-changelog.ts 是独立的小工具node scripts/extract-changelog.ts path version从指定 Changelog 中按版本号抽取对应条目并输出到 stdout——与 prepare-release 中抽取发布 PR 正文的用法一致也便于本地手动核对某个版本包含哪些提交。4. 条目格式的来源Changelog 中**scope:** description (#PR) (commit)的标准格式、小节归类feat → Features、fix → Bug Fixes 等、以及small标记 patch 版本的排版均由vitejs/release-scripts的generateChangelog统一生成这与 commit 采用 conventional commits 规范如feat(bundled-dev): ...、fix(css): ...直接对应。文档正文中 8.0.0、7.0.0、6.0.0 三个大版本条目内嵌的公告文案与链接则是在自动生成的骨架上人工补充的发布公告内容。七、升级实操如何用这份 Changelog 做版本决策判断升级风险先看小节层级patch 版本标题带small一般只有 Bug Fixes 与依赖升级可直接跟进minor/major 版本则必须逐条阅读BREAKING CHANGES若存在与Features。按 scope 过滤与自身相关的条目升级前用 scope 关键词自查例如使用 CSS 预处理器的项目重点看css/sass/lightningcss条目SSR 项目看ssr/module-runner多环境项目看environments/config。以 7.0 为例css: remove sass legacy API support (#19977)这类条目直接决定旧 sass 配置是否必须迁移。通过 PR 号回溯细节每条记录都带 PR 链接描述含糊时如remove import.meta.hot.accept resolution fallback应回到 PR 查看讨论与测试确认自己的代码是否命中该行为。关注deps类条目对工具链的间接影响如update rolldown to 1.1.2表明该版本内建打包器行为可能随 Rolldown 变化8.0 中update esbuild from ^0.25.0 to ^0.27.07.3.0 条目则提示 esbuild peer 依赖范围已变化。beta 版本按需查阅如果项目使用了highly experimental full bundle mode8.0 引入的 bundled-dev等新能力应额外阅读 Beta Changelogs 中对应 tag 的归档记录因为相关修复散落在 beta 周期内。对照迁移文档Changelog 大版本条目头部都列有 Migration Guide 入口仓库内对应 docs/guide/migration.mdVite 8 的背景与实测数据可进一步参考 docs/blog/announcing-vite8.md。小结packages/vite/CHANGELOG.md 不仅是一份版本清单也是观察 Vite 架构演进的高质量一手材料6.0 奠定了 Environment API7.0 收紧了 Node/模块体系并切换 sass compiler API8.0 完成了 Rolldown 合并这一自 Vite 2 以来最大架构变更8.1–8.2 则围绕 chunk import map、顶层input、WASM ESM 集成与 bundled-dev 持续深化。其条目格式scope PR commit、小节分类与small版本标记由 scripts/prepare-release.ts 驱动的发布流水线自动生成tag 命名与 scripts/releaseUtils.ts 中的三个发布包一一对应。掌握这套格式规范后你可以在数分钟内从 2400 行的记录中精准定位与项目相关的变更完成一次有依据的 Vite 升级决策。【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考