一个更好用的 Bump Version

11 个月前(已编辑)
1568
5
这篇文章上次修改于 8 个月前,可能部分内容已经不适用,如有疑问可询问作者。

前段时间,重写了一下 Bump Version,也增加一些功能。写篇文档介绍下。

这是个啥

Bump Version 是个用于更新 NPM 包的工具,可以一键完成更新版本号,同时生成 changelog。

如何使用

npm i -g @innei/bump-version
bump

如果没有配置的话,默认只是更新版本号,然后打一个 git tag,之后一起 push,就没有别的什么操作了。这是最常规的操作。

这就肯定远远不够。

特征

钩子

此工具支持在更新版本之前和之后的钩子。利用钩子可以执行一些脚本。

比如在更新版本之前先执行构建,更新版本之后执行推送资源文件。就可以这样子写:

{
  "before": [
      "git pull --rebase",
      "npm run build"
    ],
    "after": [
      "sh ./scripts/assets-push.sh"
    ]
}

这段配置可以写在 package.json 中,也可以单独写在 .bumprc 中。

所有的脚本执行的输出都可见,非常的好用。

Monorepo 支持

Monorepo 支持还是要有的。默认是独立版本更新,也就是只更新根目录的 package.json。当开启 "mode": "monorepo" 并且设定 packages 目录时,就可以一键更新所有子包的版本号了,如下。

{
  "mode": "monorepo",
  "packages": [
    "test/packages/*"
  ]
}

生成 Changelog

开启生成 changelog 之后,会自动识别当前项目的 changelog 文件名,他可能是 CHANGELOG 也可能是 Changelog 等等,会识别到,然后覆盖其内容。如果原先没有的话,会生成CHANGELOG.md 文件。

{
  "changelog": true
}

黑白名单

这里提供了一个选项,允许你禁止特殊分支执行 bump version,比如你不想被污染其他分支,这不是主分支。在主分支中,只允许发布稳定版本,禁止发布不稳定版本。相反,开发分支不允许发布稳定版本只是不稳定。没关系。只需将配置写如下。

{
  "allowed_branches": [
    "main",
    {
      "name": "dev/*",
      "allow_types": ["premajor", "preminor", "prepatch", "prerelease"]
    }
  ]
}

遇到 ban 到的分支就会报错。

Git Tag 模式

如果一个项目由多个人共同维护,需要同时发版时总会遇到一些问题。其他开发者可以发布自己的不稳定版本,发布操作将基于新版本创建一个 Git Tag。因此,如果另一个开发者在同一个 base 上同时创建新版本,他将得到一个冲突错误,因为新的 Git Tag 已经存在于远程分支上了。

例如,开发者 A 和开发者 B 从 master 分支切出私有分支后,修复一个 bug,需要发版验证。此时项目的版本都是 1.0.0,A 在私有分支发布了新版本同时创建了 Git Tag 1.0.0-alpha.0 并推送到远程仓库了。B 也在私有分支发布了新版本同时创建了 Git Tag 1.0.0-alpha.0,这时候就会出现冲突。

所以,这个工具现在提供了一个新模式,它可以获取远程仓库的所有 Git Tags,并根据这些顺序生成正确的版本,并且不会生成冲突的版本号。

现在如果你的 Git Tags 中存在 1.0.1 的 Tag,但项目当前版本是 1.0.0,那么下一个 patch 版本将生成为1.0.2,跳过冲突的 1.0.1.

另一个例子,如果 Git Tags 有标签1.2.0、1.3.0,项目当前版本是 1.1.0,理论上下一个 minor 版本是1.2.0,但如果启用这个特性,它将生成一个不冲突的版本为 1.4.0。

{
  "with_tags": true,
  "remote_tags": true
}

以上就是全部功能了。欢迎使用。

评论区加载中...