企业官网建设流程全解析

Vite CHANGELOG 详解：从 6.0 到 8.2.2 的版本演进、生成机制与升级实操指南

【免费下载链接】viteNext generation frontend tooling. It's fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite

packages/vite/CHANGELOG.md 是 Vite 核心包的官方版本变更记录，完整记录了 Vite 6.0.0（2024-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 条目：## <small>8.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:** don't pass empty targets to lightningcss (#23295) (2804636)

三个信息位各有用途：

1. 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）表示影响范围较广的核心行为修复；
2. PR 号是理解变更细节的最佳入口——每条记录都对应一个可追溯的 Pull Request，从 scope 和描述可以定位到具体 issue/PR 讨论；
3. 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.0

Changelog 中三个大版本条目都附有发布公告、文档与迁移指南的入口，正文信息量远大于 patch 版本，是升级判断的核心依据。

Vite 6.0.0（2024-11-26）：Environments API 登场

6.0.0 条目 是文档中信息密度最高的大版本之一，核心是Environment API（Environment 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.0（2025-06-24）：环境收紧与构建体系切换

7.0.0 条目 的 BREAKING CHANGES 小节集中体现了这一版"做减法"的主题：

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.0（2026-03-12）：Rolldown 合并，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 与 CSS：wasm: 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.0（2026-06-23）与 8.1.0-beta.0（2026-06-15）

8.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)；
• CSS：css: 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 路径别名可用于 CSS@import；8.1.4 中legacy: prefer oxc as minifier (#22468)表明@vitejs/plugin-legacy的压缩器也切换到了 Oxc。

8.2.0（2026-07-30）至 8.2.2（2026-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 正式版）与don't 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.1（L46-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）、resolve（preserveSymlinks生效于 root 解析，#23198）、define对$前缀键的正则转义匹配（#23249）等细节。

五、Beta 版本归档与历史版本入口

Changelog 对 beta 版本采用外链归档而非全文内联：8.0.0 条目末尾的 Beta Changelogs 小节 逐条列出 8.0.0-beta.0（2025-12-03）至 beta.18（2026-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 与发布 PR

scripts/prepare-release.ts 在 CI 中运行，核心调用来自@vitejs/release-scripts：

const { 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 做版本决策

1. 判断升级风险先看小节层级：patch 版本（标题带<small>）一般只有 Bug Fixes 与依赖升级，可直接跟进；minor/major 版本则必须逐条阅读BREAKING CHANGES（若存在）与Features。
2. 按 scope 过滤与自身相关的条目：升级前用 scope 关键词自查，例如使用 CSS 预处理器的项目重点看css/sass/lightningcss条目；SSR 项目看ssr/module-runner；多环境项目看environments/config。以 7.0 为例，css: remove sass legacy API support (#19977)这类条目直接决定旧 sass 配置是否必须迁移。
3. 通过 PR 号回溯细节：每条记录都带 PR 链接，描述含糊时（如remove import.meta.hot.accept resolution fallback）应回到 PR 查看讨论与测试，确认自己的代码是否命中该行为。
4. 关注deps类条目对工具链的间接影响：如update rolldown to 1.1.2表明该版本内建打包器行为可能随 Rolldown 变化；8.0 中update esbuild from ^0.25.0 to ^0.27.0（7.3.0 条目）则提示 esbuild peer 依赖范围已变化。
5. beta 版本按需查阅：如果项目使用了highly experimental full bundle mode（8.0 引入的 bundled-dev）等新能力，应额外阅读 Beta Changelogs 中对应 tag 的归档记录，因为相关修复散落在 beta 周期内。
6. 对照迁移文档：Changelog 大版本条目头部都列有 Migration Guide 入口，仓库内对应 docs/guide/migration.md，Vite 8 的背景与实测数据可进一步参考 docs/blog/announcing-vite8.md。

小结

packages/vite/CHANGELOG.md 不仅是一份版本清单，也是观察 Vite 架构演进的高质量一手材料：6.0 奠定了 Environment API，7.0 收紧了 Node/模块体系并切换 sass compiler API，8.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. It's fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite