后端Web框架SSR【免费下载链接】vinextVite plugin that reimplements the Next.js API surface — deploy anywhere项目地址https://gitcode.com/gh_mirrors/vi/vinext点击查看免费下载本文以 vinext 仓库根目录下 .changeset/README.md 为骨架结合仓库内的发布脚本、CI 工作流与真实 changeset 文件完整讲解这套「Conventional Commits → 自动 changeset → Version PR → npm 发布」的版本管理方案。读完你将掌握如何在 CI 中从提交信息自动生成 changeset、如何用beta预发布模式发布1.0.0-beta.x并让npm install vinextbeta可用、以及如何用.changeset/sha.md追溯性修正一个已经合并的提交的版本号与 changelog 条目。一、Changesets多包仓库的版本与发布工具.changeset目录由changesets/cli自动生成。这是一款面向多包multi-package仓库与单包仓库的版本管理、changelog 生成与发布工具核心思路是每次变更先用一份「changeset」描述会影响哪些包、升到什么版本号再由工具集中消费这些 changeset统一生成 Version PR、改写各包的package.json版本与CHANGELOG.md最后执行发布。在 vinext 仓库中这一流程被进一步定制大部分 changeset 不再靠人工编写而是由 scripts/create-changeset.mts 在 CI 中从 Conventional Commits 自动生成仓库当前处于prereleasebeta模式由 .changeset/pre.json 记录状态发布环节通过 scripts/publish.mts 与 scripts/version.mts 定制分别解决「beta 版本默认安装」与「changelog 按提交类型分组、追加 Contributors 列表」的问题。对应地根目录 package.json 中声明了changesets/cli依赖并提供了changeset脚本入口pnpm changeset或仓库统一的vp exec changeset。二、目录与配置.changeset/config.json 与 pre.json仓库的.changeset目录实际包含三类文件在 .changeset/ 下均可找到实例配置与状态文件config.json 与 pre.json人工提交的 changeset以形容词-名词-动词.md风格随机命名例如 enter-v1-beta.md该文件用major声明了首次 1.0 beta 发布CI 自动生成的 changeset统一以auto-前缀命名例如 auto-_vinext_cloudflare_1.0.0-beta.8-ccc7c20.md。config.json 关键字段.changeset/config.json 的配置要点如下字段当前值含义changelogchangesets/cli/changelog使用 Changesets 默认 changelog 生成器仓库随后会用 scripts/version.mts 重写为按类型分组的形式commitfalse不自动生成版本提交信息accesspublic发布到 npm 公共源baseBranchmain以main为基准分支updateInternalDependenciespatch内部依赖的最低更新级别bumpVersionsWithWorkspaceProtocolOnlytrue仅对使用 workspace 协议的依赖执行版本联动pre.json预发布模式的现场状态.changeset/pre.json 记录了mode: pre、tag: beta以及进入预发布时各包的initialVersions如vinext: 0.2.1、vinext/cloudflare: 0.2.1、create-vinext-app: 0.2.0。从 packages/vinext/CHANGELOG.md 可以看到vinext当前已推进到1.0.0-beta.11说明自进入 beta 模式以来已累积了多个迭代版本。三、CI 自动生成 changesetcreate-changeset.mts 与 release.yml3.1 整体流程根据 .github/workflows/release.yml每次向main推送时单个 Release 工作流依次执行node scripts/create-changeset.mts从 Conventional Commits 生成auto-*.mdchangeset只写入 CI 工作树working tree从不提交到main——它们存在的唯一目的就是供changesets/action消费进持续滚动维护的 Version Packages PRchangesets/action接管其余工作只要还有 changeset 存在就维护滚动更新的 Version PR当 Version PR 刚合并、changeset 为空时则执行发布通过 npm OIDC trusted publishing provenance 签名并创建 git tag 与 GitHub Release。工作流中的关键定制点version:阶段运行node scripts/version.mts即changeset version外加 Contributors 列表publish:阶段运行node scripts/publish.mts仅发布有变更的包并让预发布版本成为默认安装。3.2 提交类型到版本号的映射scripts/create-changeset.mts 中定义了核心映射表TYPE_BUMPConventional Commit 类型对应 bumpfeatminorfix/perf/revertpatchrefactor/docs/test/ci/build/chore/style不发布null同时parseBumpFromSubject会识别两种特殊情况主题中含!如feat!:或提交正文含BREAKING CHANGE:脚注时直接判定为major覆盖上表结果。affectedPackages则通过最长目录优先匹配的规则把每个变更文件归属到对应包——一个提交只会为其实际改动的包产生 bump。3.3 发布与生成的互斥保护由于自动 changeset 每次推送都会从「最近一次发布 tag」到HEAD全量重算保证幂等、避免在main上累积 changeset刚合并 Version PR 后若立即重新生成就会把刚发布的提交再次捡起来、重新打开 Version PR。为此decideGeneration实现了一个保护只要任一包的package.json版本高于其最近 tag说明已版本化、等待发布整个工作区就停止生成hasPendingPublish让changesets/action直接进入发布而非重新开 PR。这也解释了为什么发布触发刚好在 Version PR 合并后发生。3.4 生成的 changeset 长什么样一个自动生成的 changeset 由 frontmatter各包的 bump 声明 正文以-开头的提交摘要组成例如 auto-_vinext_cloudflare_1.0.0-beta.8-ccc7c20.md--- cloudflare/workers-response-store: minor vinext/cloudflare: major vinext: major --- - feat(response-store): read response metadata from R2 (#3339) - fix(cache): bypass shared lookup for force-dynamic routes (#3346) - refactor(cloudflare): route traffic-aware warming through standard prewarming (#3338) - ...文件名auto-起始引用-HEAD 短哈希.md记录了这次 changeset 覆盖的提交区间便于追踪。四、beta 预发布模式从 1.0.0-beta.0 到稳定版仓库当前运行在 Changesets 的 prerelease 模式pre.json中标明tag: beta进入模式首次 Version Packages PR 会把vinext、vinext/cloudflare、create-vinext-app统一发布为1.0.0-beta.0。仓库中 enter-v1-beta.md 正是这个入场券--- vinext/cloudflare: major create-vinext-app: major vinext: major --- Release the first vinext 1.0 beta.迭代发布后续每次 Version PR 递增 beta 号1.0.0-beta.1、beta.2……changeset publish会把它们发布到 npm 的betadist-tag。此时安装预发布版用npm install vinextbeta退出 beta当 beta 稳定、准备转正时运行vp exec changeset pre exit并提交随之更新的 .changeset/pre.json。下一次 Version Packages PR 会移除预发布后缀发布时切到 npm 的latestdist-tag成为默认安装版本。一个实现细节如何让 beta 版本默认可装Changesets 在 pre 模式下会强制把 dist-tag 设为预发布名并拒绝--tag latest。而 vinext 希望在 beta 阶段就让npm install vinext默认拿到-beta.*版本。为此 scripts/publish.mts 实现了withHiddenPrereleaseState发布前把pre.json临时改名备份、发布后再恢复finally中保证即使发布失败也会还原从而在保留已版本化的-beta.*版本号的同时把它们发布到latesttag。发布参数publishArgs在存在pre.json时追加--tag latest。五、手写 changeset何时需要、怎么写虽然 CI 会自动生成大部分 changeset但你依然可以手写人工提交到main的.changeset/*.md会被与自动生成的一并消费构建 Version PR 时两者都算数当你需要覆盖或补充提交驱动的版本号时用pnpm changeset # 或 vp exec changeset添加一份手写 changeset 即可。一个典型的手写 changeset 只有几行frontmatter 声明各包 bump正文写变更说明。六、追溯性修正提交.changeset/ .md 覆盖机制这是 .changeset/README.md 中最重要的定制功能值得单独展开。6.1 为什么需要它普通手写 changeset 只能抬高bumpChangesets 取所有声明的最大值无法降低一个已合并提交的版本而自动 changeset 每次推送都会从提交信息重新生成也无法通过编辑它们来修正标签错误的提交。比如一个实际是小修复、却以feat:minor合并的 PR无法靠常规手段降级为fix:patch。6.2 做法提交一份文件名是提交 SHA的 changeset.changeset/sha.md。发布工具链会把这个提交当作 frontmatter 中声明的 bump 处理忽略其提交信息暗示的 bump并把 changeset正文作为该提交的 changelog 条目——同时覆盖 semver bump、changelog 分组和消息文本。例如要把一个以feat:合并本会升 minor的 PR 降级为fix:patch并改写文案--- vinext: patch --- correct interception route matching for sibling segments (#1234)保存为.changeset/6005541c0a1b2c3d.md使用完整 SHA7 位前缀也可。随后该条目会以- correct interception route matching for sibling segments (#1234)出现在Bug Fixes分组下。6.3 frontmatter bump 与 changelog 分组的映射Frontmatter bump被视作Changelog 分组patchfixBug FixesminorfeatFeaturesmajorfeat!Features无包 / 空chore丢弃因此一份空白的、不带任何包声明的 SHA 命名 changeset会直接抑制suppress该提交不产生发布也不进入 changelog。这在源码中有明确对应shaFromChangesetFilename识别 7–40 位十六进制字符的 changeset 文件名bumpToOverride将 frontmatter bump 映射回 conventional 类型loadOverrides对无包声明的文件按chore处理。6.4 注意事项它是真正的 changesetchangesets/action会消费它参与 bump 计算并在发布时删除它因此覆盖不会累积无需手动清理正文成为 changelog 条目以纯 bullet 渲染替换提交信息的描述、scope 等全部内容。建议保持单行、小写开头、带 PR 引用与其它条目风格一致若留空正文则保留原提交信息的描述、仅重新分类类型声明与提交实际影响的相同包并写上你想要的 bumpscripts/create-changeset.mts负责 bump 计算与 scripts/version.mts负责 changelog 分组与消息都识别该机制均以文件名中的 SHA 为键。applyOverrides会同时清空提交正文中的BREAKING CHANGE:脚注避免它重新抬高 bump。七、changelog 生成按类型分组与 Contributors 列表发布链路的另一处定制在 scripts/version.mts运行完changeset version后脚本会重写每个被 bump 包的最新 changelog 段落按 Conventional Commit 类型分组为### Features/### Bug Fixes/### Performance/### Reverts每个类型内若某 scope如app-router、cache达到 3 条以上条目则单独开#### Area子分组scope 会经humanizeArea转成可读区域名并特判i18n、css、ppr、rsc、cdn、ssr、api、og、url、html、cli等缩写追加### Contributors列表从gh api repos/owner/repo/compare/from...HEAD分页拉取sha → login映射只统计该包自己的提交并经dedupeSortLogins去重、过滤 bot[a-zA-Z0-9-]之外的形状丢弃后排序。一个值得注意的细节Contributors 用###而非##标题是因为 Changesets 的getChangelogEntry以「## 版本号到下一个同级##」为界截取 GitHub Release 正文若用## Contributors会截断 Release 说明。从 packages/vinext/CHANGELOG.md 的1.0.0-beta.11段落可以看到这套机制的成品效果Features / Bug Fixes 分组下的**Tracing:**、**Response Store:**等加粗区域标签以及底部的 Contributors 列表。八、实战小结把整条链路串起来vinext 的版本发布是这样一个闭环开发者按 Conventional Commits 规范提交feat:、fix:、perf:等必要时加!或BREAKING CHANGE:脚注推送到main后.github/workflows/release.yml 中的create-changeset.mts从上次 tag 到HEAD全量重算生成仅存在于 CI 工作树的auto-*.mdchangesets/action将这些 changeset连同人工提交的滚动进 Version Packages PR若恰好刚合并完 Version PR则改为直接发布发布时 scripts/publish.mts 借助临时隐藏pre.json的技巧把1.0.0-beta.x发布到latesttagbeta 阶段即可默认安装scripts/version.mts 负责把 changelog 重写为分组 Contributors 的成品若某提交标签错误提交.changeset/sha.md即可追溯性修正 bump 与 changelog且发布后自动清理不产生累积。这套设计的核心价值在于版本号与 changelog 不再依赖人工维护全部由提交信息驱动同时保留了两处可控的人肉闸门——手写 changeset 覆盖以及 SHA 命名 changeset 的追溯修正兼顾了自动化与精确性。赞分享后端Web框架SSR【免费下载链接】vinextVite plugin that reimplements the Next.js API surface — deploy anywhere项目地址https://gitcode.com/gh_mirrors/vi/vinext点击查看免费下载相关推荐vinext 版本发布是如何发生的以 1.0.0-beta.5 自动 Changeset 为例解析 Conventional Commits 与 Changesets 流水线vinext 版本发布是如何发生的以 1.0.0 beta.5 自动 Changeset 为例解析 Conventional Commits 与 Change后端Web框架SSRqiankun 仓库的 Changesets 提交驱动发布机制从 Conventional Commits 到 npm 发布与 GitHub Release 全流程解析qiankun 仓库的 Changesets 提交驱动发布机制从 Conventional Commits 到 npm 发布与 GitHub Release前端微前端Trigger.dev 发布流程深度解析从 changesets 到一键发布的自动化流水线Trigger.dev 发布流程深度解析从 changesets 到一键发布的自动化流水线 导读 本文基于 RELEASE.md https://link.gAI Agent后端任务调度开发工具可观测性AI 应用上一篇如何快速安装HGNNPython 3.6 PyTorch 0.4.0完整配置教程下一篇kohya_ss极速安装指南Linux系统UV部署方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考