前言

上回我们说到组件库的工程搭建流程和相关的方法踩坑论，俗话说，无规矩不成方圆。这次我们要聊聊关于标准化的事，这其中就包括版本管理的规范和代码开发提交规范。

版本管理

谷歌上对于版本控制的定义如下：“版本控制（英语：Version control）是维护工程蓝图的标准作法，能追踪工程蓝图从诞生一直到定案的过程。此外，版本控制也是一种软件工程技巧，借此能在软件开发的过程中，确保由不同人所编辑的同一程序文件都得到同步。”对于组件库来说，版本管理也尤其的重要，确保用户使用的便利性和开发的统一规范性。

目标

组件库的版本号需要满足语义化版本2.0的规则；
自动生成相应版本的Change Log。

解决方案

一般Change Log都是依赖于每次的commit信息，因此只要把对应的commit信息进行规范化，自动化工具就可以从其中提取出更新的关键信息，从而自动生成到Change Log中去。

commit规范化

目前，社区有多种commit message的写法规范，使用最广泛的是Angular规范，其中关于提交类型type的总结如下：

标识名	说明
feat	新功能
fix	bug修复
docs	文档更新
chore	不属于以上类型的其他类型，比如构建流程, 依赖管理
style	不影响程序逻辑的代码修改(修改空白字符，格式缩进，补全缺失的分号等，没有改变代码逻辑)
feat	新功能
refactor	重构代码(既没有新增功能，也没有修复 bug)
test	新增测试用例或是更新现有测试
build	主要目的是修改项目构建系统(例如 glup，webpack，rollup 的配置等)的提交
ci	主要目的是修改项目继续集成流程(例如 Travis，Jenkins，GitLab CI，Circle等)的提交
revert	回滚某个更早之前的提交

安装commitizen

1. yarn add commitizen --dev
2. commitizen init cz-conventional-changelog --yarn --dev --exact
// 会自动安装cz-conventional-changelog以及生成相应的config配置项

增加scripts脚本

"scripts": {
  "commit" : "git-cz"
}

执行yarn commit之后，启动commitizen进行commit提交信息校验

> git cz

cz-cli@4.0.3, cz-conventional-changelog@3.0.2

? Select the type of change that you're committing: (Use arrow keys)
> feat:        A new feature
  fix:         A bug fix
  improvement: An improvement to a current feature
  docs:        Documentation only changes
  style:       Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  refactor:    A code change that neither fixes a bug nor adds a feature
  perf:        A code change that improves performance
(Move up and down to reveal more choices)

使用commitizen进行commit信息校验的一个最大问题在于，并不是所有的开发者都选择用命令行的形式进行代码提交的，如果借助类似于vscode中的git自动提交管理，commit信息就无法进行拦截和控制，这个时候就需要commitlint+husky的组合出马了！

commitlint

安装commitlint/cli

npm install --save-dev @commitlint/config-conventional @commitlint/cli

增加scripts脚本

"scripts": {
  "commitlint" : "npx commitlint -e $HUSKY_GIT_PARAMS"
}
// -e而不是-E, 后面的环境变量参数前面需要加上$

配置commitlint相应提交规范

可以通过commitlint.config.js，.commitlintrc.js，.commitlintrc.json，或.commitlintrc.yml文件等方式配置，同时也可以在package.json中配置。

module.exports = {
  extends: ['@commitlint/config-conventional']
}
// @commitlint/config-conventional是基于Angular的规范配置插件

husky

husky继承了 git 下所有的钩子，在触发钩子的时候，可以阻止不合法的 commit、push 等等，当前的版本为^6.0.0，对应操作步骤如下：

yarn add husky --dev
npx husky install
npx husky add .husky/pre-commit "npm run prettier"

安装husky包；
开启git hooks，在项目的根目录下创建一个.husky文件夹；
创建钩子，后面跟的是钩子触发阶段会执行的脚本，该命令会在.husky文件夹下生成pre-commit文件，对应文件下的脚步是npm run prettier，脚本会在commit之前触发。注：不需要配置.huskyrc/.huskyrc.js文件

自动生成Change log

通过开源工具conventional-changelog-cli自动生成log

安装

yarn add conventional-changelog-cli --dev

增加scripts脚本

"scripts": {
  "changelog": "npx conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
}

生成的 CHANGELOG 最终样式如下：

# 1.0.0 (2019-11-06)

### Features

- **自动化:** 新增自动生成 CHANGELOG 相关功能 ([a9ebf7e](https://github.com/godbasin/wxapp-typescript-demo/commit/a9ebf7ee0ca53a4906ed77106b65f6d6bef92f9b))

版本标准化

通过standard-version进行自动化版本控制。

安装

yarn add standard-version --dev

增加scripts脚本

"scripts": {
  "release": "npx standard-version --no-verify -t release-"
}

一般执行release是在所有的版本分支代码都合并到master上确认无误后再进行版本的发布。

总结

关于版本控制和开发提交规范，不仅仅适用于组件库项目场景，同时也适用于我们的业务项目开发，因此增加这些规范更有利于提升开发的效率和质量，后续还会更新组件API设计规范和自动化发布相关的分享总结，敬请期待～

再谈谈组件库标准化

前言