一个更好用的 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
}

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

评论区加载中...