开源项目常用工具对比：（一）版本管理/发布工具对比： release-it VS standard-version （优化版）

菲鸽
419 阅读6分钟

开源项目常用工具对比：（一）版本管理/发布工具对比： release-it VS standard-version （优化版）

编写开源项目时，通常需要控制版本、生成CHANGELOG等内容，我们通常会借助第三方工具来完成，现在就来介绍常用的2个工具 release-it 和 standard-version.

Release-it

功能

  • 版本管理：自动在 package.json 中递增版本号，支持预发布版本管理。
  • 日志生成：自动生成变更日志，支持通过插件扩展日志格式。
  • Git 操作：自动执行 Git commit、tag、push 等操作，将代码推送到远程仓库。
  • 发布流程：支持自动发布到 npm、GitHub、GitLab 等平台，创建发行版。
  • 构建与测试：通过 Hooks 执行测试、构建等命令。
  • 插件支持：强大的插件体系，可以扩展功能。

使用方式

  1. 安装：通过 npm 安装 release-it： 
    npm install release-it --save-dev
  2. 配置：在项目根目录下创建配置文件 release-it.json 或在 package.json 中添加配置项，例如： 
    {
  "release-it": {
    "git": {
      "commit": true,
      "tag": true,
      "push": true
    },
    "npm": {
      "publish": true
    }
  }
}
  3. 运行：在 package.json 中添加脚本： 
    {
  "scripts": {
    "release": "release-it"
  }
}
    然后执行 npm run release 来触发版本发布。

应用场景

  • 适用于需要完整自动化发布流程的项目，尤其是 npm 包、GitHub 项目等。
  • 适合在持续集成和持续部署（CI/CD）环境中使用，提高开发团队的工作效率。

Standard-version

功能

  • 版本号更新：根据提交信息自动更新版本号，遵循语义化版本规范。
  • 日志生成：自动生成 CHANGELOG.md 文件，记录新增功能、修复的 bug 等详细信息。
  • Git 操作：创建 Git tag，但不会自动推送代码。
  • 生命周期脚本：允许在 release 过程中执行自定义的命令，如 prebump、postbump、prechangelog 等。

使用方式

  1. 安装：通过 npm 安装 standard-version： 
    npm install standard-version --save-dev
  2. 配置：在项目根目录下创建配置文件 .versionrc 或在 package.json 中添加配置项，例如： 
    {
  "scripts": {
    "prebump": "echo 'Running prebump script'",
    "postbump": "echo 'Running postbump script'"
  }
}
  3. 运行：在 package.json 中添加脚本： 
    {
  "scripts": {
    "release": "standard-version"
  }
}
    然后执行 npm run release 来触发版本发布。

应用场景

  • 适合需要版本号更新和日志生成的项目，尤其是遵循 Conventional Commits 规范的项目。
  • 适用于个人开发者或团队开发者，简化版本控制和发布流程。

对比总结

自动化程度

  • Release-it：自动化程度更高，可以完成从版本更新到代码推送、日志生成、平台发布的整个流程。
  • Standard-version：主要专注于版本号更新和日志生成，不会自动推送代码或发布到 npm 等平台。

灵活性和扩展性

  • Release-it：配置灵活，支持通过插件扩展功能，可以更好地适应不同项目的需求。
  • Standard-version：配置相对简单，但足以满足基本的版本管理和日志生成需求。

社区和生态

  • Release-it：被广泛应用于 npm 包、GitHub 项目等的自动化发布，如 Redux、Axios 等知名开源项目。
  • Standard-version：也具有一定的用户基础，尤其在遵循 Conventional Commits 规范的项目中。

适用场景

  • Release-it：如果项目需要完整的自动化发布流程，包括代码推送和平台发布，是更好的选择。
  • Standard-version：如果只需要版本号更新和日志生成，可以满足需求。

表格对比

以下是 release-it 和 standard-version 在版本管理和发布方面的功能对比表格：

功能/特性release-itstandard-version
版本号升级自动更新 package.json 中的版本号，支持手动指定版本号。根据提交信息中的类型自动计算版本号。
Git 操作自动执行 Git 提交、标签创建和推送。使用 Git tag 为新版本打上标签。
Changelog 生成自动生成变更日志。自动生成和更新 Changelog。
npm 发布支持自动发布到 npm 注册表。支持发布到 npm 仓库。
插件扩展支持插件扩展功能，可与多种工具集成。支持通过生命周期脚本的高级用法进行定制。
预发布管理支持管理 alpha、beta 和 rc 等预发布版本。不支持预发布版本管理。
交互式体验提供友好的命令行界面，允许用户确认每一步操作。无交互式体验，完全自动化。
配置灵活性支持通过配置文件进行详细定制。支持通过配置文件（如 .versionrc）进行定制。
CI/CD 集成支持从任何 CI/CD 环境进行发布。可以集成到 CI/CD 流程中。
钩子机制在发布流程的不同阶段执行自定义命令。支持生命周期脚本，如 prebump、postbump 等。
适用范围适用于各种类型的项目，不仅仅是 npm 包。主要用于 npm 包的版本管理和发布。

综上所述，release-it 和 standard-version 都是优秀的版本管理和发布工具，各有优势。选择时可以根据项目的具体需求、团队的使用习惯以及对自动化程度的要求来决定使用哪个工具。

菲鸽 unibest 的选择

原本我想在 unibest 中引入 release-it，然后看到 wot-ui 用的是 standard-version, 于是就做了个对比。

经我调查， 前端生态中 vuejs、vitejs、react 这样的项目用的都是 standard-version。

既然如此， unibest 会使用 standard-version 作为版本控制工具，敬请期待。

unibest 链接地址

欢迎体验，欢迎star!

下面的是旧账号和旧文档，留个纪念。

补充说明(2025-01-08)

1. 版本号升级规则

standard-version 是基于语义化版本控制（Semantic Versioning）和约定式提交（Conventional Commits）规范来自动升级版本号的。其升级版本号的规则如下：

  • 主版本号（MAJOR）：当提交信息中包含 BREAKING CHANGES 时，会升级主版本号。这通常意味着有不兼容的 API 变更。
  • 次版本号（MINOR）：当提交信息类型为 feat（新功能）时，会升级次版本号。这表示添加了向后兼容的新功能。
  • 补丁版本号（PATCH）：当提交信息类型为 fix（修复）时，会升级补丁版本号。这表示进行了向后兼容的 bug 修复。

如果当前版本号没有主版本号（例如 0.1.2），则包含 BREAKING CHANGES 的提交不会自动升级主版本号。在这种情况下，需要手动指定版本号的升级，例如使用 standard-version --release-as major 来强制升级主版本号。

2.其他分支合并过来的能否检测出来

可以的。 比如 unibest 有 base main i18n 等多个分支，主要代码在 base 里面编写，然后会合并到其他所有分支，合并到 main 分支时合并的消息是 Merge branch 'base'，但是在 main 分支执行 pnpm release 时同样可以识别出 base 分支里面的提交信息，可以正常生成想要的 CHANGELOG 记录。

avatar
文章
阅读
粉丝