通过 standard version 自动化升级版本号、生成 changelog 及 tag

1.安装 standard-version（github地址）

npm install -D standard-version
或
yarn add -D standard-version

2.自动化升级版本号、生成 changelog 及 tag

1.添加到 package.json 脚本命令

// package.json
"scripts": {
    // ...
    "release": "standard-version"
}

2.通过 yarn release 或者 npm run releas 运行

CHANGELOG 文件如下，可以看提交记录会被写入 CHANGELOG 文件；但默认只会写入 feat、fix 类型的提交记录。

3.通过 .versionrc 配置往 CHANGELOG 中写入更多类型的提交记录

{  
    "types": [   
        {     
           "type": "chore",   // 类型
           "section": "Other",   // 在 CHANGELOG 文件中的分类名
           "hidden": false   // 是否不在 CHANGELOG 中显示
       } 
    ]
}

3.将 tag 推到远程

// package.json
"scripts": {
    // ...
   // "release": "standard-version"
   "release": "standard-version && git push --follow-tags"
}

至此，在项目发布前只需要运行一下 yarn release 就能完成版本号升级、CHANGELOG 更新以及创建新 tag

4.standard-version 是如何工作的

首先在使用 standard-version 前需要遵循 Conventional Commits 的代码提交规范，因为 standard-version 生成 changelog 和升级版本号都是基于该规范的。

PS：以下的 bump、bumped 单词都是个人通过语境解读的，如需了解更准确的意思可以去 官网 查看

1.通过 packageFiles 检查当前版本，并回到最新 tag。
packageFiles 是用户定义的可以被读取使用和更新（bump）版本号的文件。包括 package.json, manifest.json, etc.

2. 基于提交类型更新 bumpFiles 版本号
bumpFiles 是用户定义的用于锁定（bumped）版本号的文件，该类文件不被用于读取版本号。包括 package-lock.json, npm-shrinkwrap.json, etc.

更新版本号时，会通过记录提交类型来判断更新的是哪一位版本号。在 Conventional Commits 文档中明确说明了 MAHOR、MINOR 和 PATCH 版本号对应的更新策略。分别对应的是 BREAKING CHANGE、feat、fix。提交记录类型混合时更大版本的类型优先，比如同时存在 feat 和 fix，那么更新的将是 MINOR。更加详细的可以查看文档了解。

3. 基于提交记录生成changelog
4. 自动 commit
5. 基于新版本号生成 tag

5.standard-version 的更多用法

1.首次发布，不升级版本号
yarn release -- --first-release

2. 预发版本，及前缀
yarn release -- --prerelease
假如当前版本号为 1.0.0

eg1: yarn release -- --prerelease
现在版本号为 1.0.1-0

eg2: yarn release -- --prerelease alpha
现在版本号为 1.0.1-alpha.0

3. 指定升级major/minor/patch版本号，或自定义版本号
当自动生成的版本号不是你想要的，你可以主动指定版本号， yarn release -- --release-as <version>

当前版本号 1.0.0
eg1: yarn release -- --release-as minor
现在版本号为 1.1.0

eg2: yarn release -- --release-as 2.2.0
现在版本号为 2.2.0

PS: 更多使用方法可以查阅 官网