Huly 网络层 Rush Monorepo 版本自动提升实战bump-changes-from-tag.sh 完全指南【免费下载链接】platformHuly — All-in-One Project Management Platform (alternative to Linear, Jira, Slack, Notion, Motion)项目地址: https://gitcode.com/GitHub_Trending/platform80/platform在 Hulyplatform80这样的大型 Rush.js Monorepo 中管理几十个 Node.js 包的版本号是一项繁琐且易错的工作。本文介绍的bump-changes-from-tag.sh脚本位于 foundations/net/common/scripts/bump-changes-from-tag.sh能够自动检测仓库中最新v*.*.*格式的版本标签将 Rush Monorepo 中所有包的版本统一提升到新版本并同步更新它们之间的内部依赖引用含workspace:协议依赖。读完本文你将掌握该脚本的三种调用方式、参数解析逻辑、底层两步更新原理以及从版本提升到发布的全流程操作。脚本定位一次命令搞定整个 Monorepo 的版本同步bump-changes-from-tag.sh是一个纯 Bash 脚本其设计目标在脚本头部注释中写得很清楚Script to bump version of ALL Node.js packages by incrementing from previous tag and update dependencies accordingly in a Rush.js monorepo——即从上一个版本标签出发提升全部Node.js 包版本并相应更新依赖引用。它与常见的只提升有变更的包的做法不同采用的是整个仓库统一版本号的策略。该脚本位于foundations/net这个独立 Rush 工作区中该目录拥有自己的 rush.json适用于以hcengineering/network-*为命名空间的网络层包集合。同目录下的 README.md 对其功能特性做了更全面的描述包括支持 major/minor/patch 三种提升类型、同时处理 publishable 与 private 包、兼容带注释的 rush.json、彩色输出、跨 shell 兼容bash 4 / zsh等。快速开始三种标准用法根据 README_BUMP.md 的 Quick Start脚本提供三种调用方式。运行前提是当前目录处于foundations/net的 Git 仓库内且存在rush.json与 Node.js 运行环境。Option 1自动检测 patch 提升最常用不传任何参数时脚本自动检测最新的v*.*.*标签并以 patch补丁级别提升版本./common/scripts/bump-changes-from-tag.shOption 2自动检测 指定提升类型第一个参数直接传入提升类型脚本同样自动检测标签./common/scripts/bump-changes-from-tag.sh minor ./common/scripts/bump-changes-from-tag.sh majorOption 3手动指定 Git revision当需要以某个具体标签、提交或提交区间为基线时第一个参数传 Git revision第二个参数传提升类型./common/scripts/bump-changes-from-tag.sh v0.7.0 major ./common/scripts/bump-changes-from-tag.sh HEAD~5 minor第二个参数可省略此时默认使用patchREADME.md中还给出了以具体 commit hash 为基线的示例./common/scripts/bump-changes-from-tag.sh abc1234 major。自动检测最新版本标签的原理脚本的核心亮点README_BUMP.md 特别强调是Auto-detect latest version tag。这一能力由源码中的get_latest_version_tag()函数实现bump-changes-from-tag.shgit tag -l v*.*.* | sort -V | tail -n 1三个命令各司其职git tag -l v*.*.*列出所有匹配v*.*.*通配模式如v0.7.4的标签sort -V按版本号语义而非字典序排序保证v0.10.0排在v0.9.0之后tail -n 1取出排序后的最后一个即最新版本标签。如果仓库中不存在任何匹配v*.*.*的标签函数会返回非零退出码并输出警告No version tags found matching v*.*.* pattern脚本随后打印完整 Usage 并退出退出码 1。这一失败路径是脚本的安全阀避免在无标签仓库中产生不可预期的版本号。README_BUMP.md 提到的测试脚本test-bump-tag-detection.sh用于预检 tag 自动检测结果不过该文件在当前仓库中并未随附若要验证检测逻辑可直接执行等价命令git tag -l v*.*.* | sort -V | tail -n 1观察输出。参数解析与 bump 类型校验脚本对命令行参数的解析逻辑位于 bump-changes-from-tag.sh分为三种分支首个参数行为空自动检测标签BUMP_TYPEpatchmajor/minor/patch自动检测标签BUMP_TYPE$1其他值视为 Git revisionGIT_REVISION$1BUMP_TYPE${2:-patch}随后通过case语句对BUMP_TYPE做白名单校验非法值如BUMP_TYPEfeature会输出Invalid bump type并退出。前置条件检查还包括确认当前处于 Git 仓库检查.git目录或文件存在、确认rush.json存在路径由git rev-parse --show-toplevel得到仓库根目录后拼接而成。三种提升类型的版本演算规则由increment_version()函数实现bump-changes-from-tag.sh类型版本变化语义实现逻辑patch1.2.3→1.2.4Bug 修复、小改动默认patch 位 1minor1.2.3→1.3.0新功能、向后兼容minor 位 1patch 清零major1.2.3→2.0.0破坏性变更major 位 1minor 与 patch 清零该函数对版本格式做了严格校验major.minor.patch三段必须是纯数字否则输出Invalid version format并返回失败。值得注意的是它额外支持预发布后缀先通过${version%%-*}剥离-alpha.1之类的后缀只对基础三段做增量运算最后把后缀原样拼回如1.2.3-alpha.1patch 后为1.2.4-alpha.1并在README.md的 Supported Version Formats 一节中明确声明了对1.2.3-alpha.1这类预发布版本的支持。底层实现两步更新保证依赖一致性get_tag_version()先将标签如v0.7.0去掉v前缀得到基准版本increment_version()计算得出统一的新版本号后脚本分两步完成全部更新核心循环见 bump-changes-from-tag.shStep 1读取 Rush 项目清单统一提升各包版本脚本通过 Node.js 内联脚本解析rush.jsonget_rush_projects()bump-changes-from-tag.sh。关键是它先使用正则剔除//单行注释与/* ... */多行注释再执行JSON.parse——这正是 Rush 官方配置文件允许带注释 JSON格式的正确处理方式。解析后以packageName|projectFolder|shouldPublish三字段输出每个项目。以本仓库的 foundations/net/rush.json 为例projects数组中声明了hcengineering/network-corepackages/core可发布、hcengineering/network-podpods/network-pod私有等 9 个项目。脚本对每个项目执行读取其package.json的当前版本 → 将version字段改写为新版本号 → 将packageName|新版本|projectFolder|shouldPublish|旧版本记录到临时文件mktemp -d创建的临时目录供第二步使用。Step 2交叉更新所有内部依赖引用第二步遍历每个包的package.json对其中的dependencies、devDependencies、peerDependencies三个字段由update_dependencies()函数处理bump-changes-from-tag.sh逐一检查是否引用了 Monorepo 内部包若命中则改写版本旧依赖以workspace:开头如workspace:*→ 改写为workspace:^新版本普通依赖 → 改写为^新版本。这样保证 Monorepo 内部所有互相引用都指向统一的新版本避免出现包 A 已升级、包 B 仍引用旧版本的漂移问题。临时文件在流程结束后被清理。收尾自动同步 lockfile脚本在打印 Summary 后会自动执行rush update同步 lockfilebump-changes-from-tag.sh确保rush.lock中的解析版本与新的 package.json 一致随后输出Done!。输出、安全特性与发布后续步骤脚本全程使用[INFO]、[SUCCESS]、[WARNING]、[ERROR]四种带颜色的分级输出定义于 bump-changes-from-tag.sh。README.md给出了完整的输出示例以minor提升为例输出会依次展示仓库根目录、参考 revision、提升类型、待更新包数量每个包打印Package xxx changed: 0.7.0 - 0.8.0 (minor)最后的 Summary 用✓标注已更新包并区分will be published与private package两类。内置的安全特性源码与 README 双重印证包括校验 Git 仓库与rush.json存在性缺失即报错退出严格校验 bump 类型与版本号格式使用mktemp -d临时目录存放中间数据避免污染仓库全程set -e任何一步失败立即终止防止产生半更新状态更新完成前先打印完整摘要便于人工复核。脚本末尾打印的 Next steps 给出了从版本提升到发布的完整链路# 1. 审查改动 git diff # 2. 同步 lockfile脚本末尾已自动执行过 rush update此处可复核 rush update # 3. 运行测试 rush test # 4. 构建所有包 rush build # 5. 提交改动 git add . git commit -m Bump all versions to 0.7.5 # 6. 打标签并推送 git tag v0.7.5 git push origin v0.7.5 # 7. 发布可发布包 rush publish需要说明的是README_BUMP.md 中链接的完整使用指南BUMP_USAGE.md与变更日志CHANGES.md在当前仓库中并未随附foundations/net/common/scripts 目录下仅有README.md、README_BUMP.md与脚本本身就实际可用的文档与源码而言本仓库内的 README.md 是上述链接文档内容最贴近的补充阅读材料。适用前提与限制从脚本前置条件与实现bump-changes-from-tag.sh可以归纳出以下使用约束必须运行在 Rush.js Monorepo 的 Git 仓库中且根目录存在rush.json需要 Node.js 环境脚本内联使用node -e完成 JSON 解析与改写推荐 bash 4 或 zshREADME.md 注明脚本依赖关联数组语法采用全仓库统一版本策略shouldPublish: false的私有包同样会被更新版本号预发布版本的处理保留原始后缀仅对基础三段做增量。由于 Huly 仓库规模庞大根目录 rush.json 下的项目横跨 models、plugins、server、services 等大量目录直接对根仓库执行该脚本会一次性改动所有包版本建议在独立的子工作区如foundations/net这类拥有独立 rush.json 的目录中按版本发布节奏使用以控制变更范围与发布风险。【免费下载链接】platformHuly — All-in-One Project Management Platform (alternative to Linear, Jira, Slack, Notion, Motion)项目地址: https://gitcode.com/GitHub_Trending/platform80/platform创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Huly 网络层 Rush Monorepo 版本自动提升实战：bump-changes-from-tag.sh 完全指南
Huly 网络层 Rush Monorepo 版本自动提升实战bump-changes-from-tag.sh 完全指南【免费下载链接】platformHuly — All-in-One Project Management Platform (alternative to Linear, Jira, Slack, Notion, Motion)项目地址: https://gitcode.com/GitHub_Trending/platform80/platform在 Hulyplatform80这样的大型 Rush.js Monorepo 中管理几十个 Node.js 包的版本号是一项繁琐且易错的工作。本文介绍的bump-changes-from-tag.sh脚本位于 foundations/net/common/scripts/bump-changes-from-tag.sh能够自动检测仓库中最新v*.*.*格式的版本标签将 Rush Monorepo 中所有包的版本统一提升到新版本并同步更新它们之间的内部依赖引用含workspace:协议依赖。读完本文你将掌握该脚本的三种调用方式、参数解析逻辑、底层两步更新原理以及从版本提升到发布的全流程操作。脚本定位一次命令搞定整个 Monorepo 的版本同步bump-changes-from-tag.sh是一个纯 Bash 脚本其设计目标在脚本头部注释中写得很清楚Script to bump version of ALL Node.js packages by incrementing from previous tag and update dependencies accordingly in a Rush.js monorepo——即从上一个版本标签出发提升全部Node.js 包版本并相应更新依赖引用。它与常见的只提升有变更的包的做法不同采用的是整个仓库统一版本号的策略。该脚本位于foundations/net这个独立 Rush 工作区中该目录拥有自己的 rush.json适用于以hcengineering/network-*为命名空间的网络层包集合。同目录下的 README.md 对其功能特性做了更全面的描述包括支持 major/minor/patch 三种提升类型、同时处理 publishable 与 private 包、兼容带注释的 rush.json、彩色输出、跨 shell 兼容bash 4 / zsh等。快速开始三种标准用法根据 README_BUMP.md 的 Quick Start脚本提供三种调用方式。运行前提是当前目录处于foundations/net的 Git 仓库内且存在rush.json与 Node.js 运行环境。Option 1自动检测 patch 提升最常用不传任何参数时脚本自动检测最新的v*.*.*标签并以 patch补丁级别提升版本./common/scripts/bump-changes-from-tag.shOption 2自动检测 指定提升类型第一个参数直接传入提升类型脚本同样自动检测标签./common/scripts/bump-changes-from-tag.sh minor ./common/scripts/bump-changes-from-tag.sh majorOption 3手动指定 Git revision当需要以某个具体标签、提交或提交区间为基线时第一个参数传 Git revision第二个参数传提升类型./common/scripts/bump-changes-from-tag.sh v0.7.0 major ./common/scripts/bump-changes-from-tag.sh HEAD~5 minor第二个参数可省略此时默认使用patchREADME.md中还给出了以具体 commit hash 为基线的示例./common/scripts/bump-changes-from-tag.sh abc1234 major。自动检测最新版本标签的原理脚本的核心亮点README_BUMP.md 特别强调是Auto-detect latest version tag。这一能力由源码中的get_latest_version_tag()函数实现bump-changes-from-tag.shgit tag -l v*.*.* | sort -V | tail -n 1三个命令各司其职git tag -l v*.*.*列出所有匹配v*.*.*通配模式如v0.7.4的标签sort -V按版本号语义而非字典序排序保证v0.10.0排在v0.9.0之后tail -n 1取出排序后的最后一个即最新版本标签。如果仓库中不存在任何匹配v*.*.*的标签函数会返回非零退出码并输出警告No version tags found matching v*.*.* pattern脚本随后打印完整 Usage 并退出退出码 1。这一失败路径是脚本的安全阀避免在无标签仓库中产生不可预期的版本号。README_BUMP.md 提到的测试脚本test-bump-tag-detection.sh用于预检 tag 自动检测结果不过该文件在当前仓库中并未随附若要验证检测逻辑可直接执行等价命令git tag -l v*.*.* | sort -V | tail -n 1观察输出。参数解析与 bump 类型校验脚本对命令行参数的解析逻辑位于 bump-changes-from-tag.sh分为三种分支首个参数行为空自动检测标签BUMP_TYPEpatchmajor/minor/patch自动检测标签BUMP_TYPE$1其他值视为 Git revisionGIT_REVISION$1BUMP_TYPE${2:-patch}随后通过case语句对BUMP_TYPE做白名单校验非法值如BUMP_TYPEfeature会输出Invalid bump type并退出。前置条件检查还包括确认当前处于 Git 仓库检查.git目录或文件存在、确认rush.json存在路径由git rev-parse --show-toplevel得到仓库根目录后拼接而成。三种提升类型的版本演算规则由increment_version()函数实现bump-changes-from-tag.sh类型版本变化语义实现逻辑patch1.2.3→1.2.4Bug 修复、小改动默认patch 位 1minor1.2.3→1.3.0新功能、向后兼容minor 位 1patch 清零major1.2.3→2.0.0破坏性变更major 位 1minor 与 patch 清零该函数对版本格式做了严格校验major.minor.patch三段必须是纯数字否则输出Invalid version format并返回失败。值得注意的是它额外支持预发布后缀先通过${version%%-*}剥离-alpha.1之类的后缀只对基础三段做增量运算最后把后缀原样拼回如1.2.3-alpha.1patch 后为1.2.4-alpha.1并在README.md的 Supported Version Formats 一节中明确声明了对1.2.3-alpha.1这类预发布版本的支持。底层实现两步更新保证依赖一致性get_tag_version()先将标签如v0.7.0去掉v前缀得到基准版本increment_version()计算得出统一的新版本号后脚本分两步完成全部更新核心循环见 bump-changes-from-tag.shStep 1读取 Rush 项目清单统一提升各包版本脚本通过 Node.js 内联脚本解析rush.jsonget_rush_projects()bump-changes-from-tag.sh。关键是它先使用正则剔除//单行注释与/* ... */多行注释再执行JSON.parse——这正是 Rush 官方配置文件允许带注释 JSON格式的正确处理方式。解析后以packageName|projectFolder|shouldPublish三字段输出每个项目。以本仓库的 foundations/net/rush.json 为例projects数组中声明了hcengineering/network-corepackages/core可发布、hcengineering/network-podpods/network-pod私有等 9 个项目。脚本对每个项目执行读取其package.json的当前版本 → 将version字段改写为新版本号 → 将packageName|新版本|projectFolder|shouldPublish|旧版本记录到临时文件mktemp -d创建的临时目录供第二步使用。Step 2交叉更新所有内部依赖引用第二步遍历每个包的package.json对其中的dependencies、devDependencies、peerDependencies三个字段由update_dependencies()函数处理bump-changes-from-tag.sh逐一检查是否引用了 Monorepo 内部包若命中则改写版本旧依赖以workspace:开头如workspace:*→ 改写为workspace:^新版本普通依赖 → 改写为^新版本。这样保证 Monorepo 内部所有互相引用都指向统一的新版本避免出现包 A 已升级、包 B 仍引用旧版本的漂移问题。临时文件在流程结束后被清理。收尾自动同步 lockfile脚本在打印 Summary 后会自动执行rush update同步 lockfilebump-changes-from-tag.sh确保rush.lock中的解析版本与新的 package.json 一致随后输出Done!。输出、安全特性与发布后续步骤脚本全程使用[INFO]、[SUCCESS]、[WARNING]、[ERROR]四种带颜色的分级输出定义于 bump-changes-from-tag.sh。README.md给出了完整的输出示例以minor提升为例输出会依次展示仓库根目录、参考 revision、提升类型、待更新包数量每个包打印Package xxx changed: 0.7.0 - 0.8.0 (minor)最后的 Summary 用✓标注已更新包并区分will be published与private package两类。内置的安全特性源码与 README 双重印证包括校验 Git 仓库与rush.json存在性缺失即报错退出严格校验 bump 类型与版本号格式使用mktemp -d临时目录存放中间数据避免污染仓库全程set -e任何一步失败立即终止防止产生半更新状态更新完成前先打印完整摘要便于人工复核。脚本末尾打印的 Next steps 给出了从版本提升到发布的完整链路# 1. 审查改动 git diff # 2. 同步 lockfile脚本末尾已自动执行过 rush update此处可复核 rush update # 3. 运行测试 rush test # 4. 构建所有包 rush build # 5. 提交改动 git add . git commit -m Bump all versions to 0.7.5 # 6. 打标签并推送 git tag v0.7.5 git push origin v0.7.5 # 7. 发布可发布包 rush publish需要说明的是README_BUMP.md 中链接的完整使用指南BUMP_USAGE.md与变更日志CHANGES.md在当前仓库中并未随附foundations/net/common/scripts 目录下仅有README.md、README_BUMP.md与脚本本身就实际可用的文档与源码而言本仓库内的 README.md 是上述链接文档内容最贴近的补充阅读材料。适用前提与限制从脚本前置条件与实现bump-changes-from-tag.sh可以归纳出以下使用约束必须运行在 Rush.js Monorepo 的 Git 仓库中且根目录存在rush.json需要 Node.js 环境脚本内联使用node -e完成 JSON 解析与改写推荐 bash 4 或 zshREADME.md 注明脚本依赖关联数组语法采用全仓库统一版本策略shouldPublish: false的私有包同样会被更新版本号预发布版本的处理保留原始后缀仅对基础三段做增量。由于 Huly 仓库规模庞大根目录 rush.json 下的项目横跨 models、plugins、server、services 等大量目录直接对根仓库执行该脚本会一次性改动所有包版本建议在独立的子工作区如foundations/net这类拥有独立 rush.json 的目录中按版本发布节奏使用以控制变更范围与发布风险。【免费下载链接】platformHuly — All-in-One Project Management Platform (alternative to Linear, Jira, Slack, Notion, Motion)项目地址: https://gitcode.com/GitHub_Trending/platform80/platform创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考