规范化之commitlint

项目中使用commitlint

安装依赖

npm install --save-dev @commitlint/config-conventional @commitlint/cli --registry=https://registry.npm.taobao.org 

生成配置文件.commitlintrc.js或commitlint.config.js

自定义配置文件的格式可以有多种，使用.commitlintrc.js或者commitlint.config.js都是有效的。

echo module.exports = {extends: ['@commitlint/config-conventional'],rules: {}} > .commitlintrc.js

package.json配置

"husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"	// commitlint配合husk使用
    }
}

备注：commitlint 是规范git commit 备注信息使用的，因此要配合Git Hook使用，本文为博主本人近期前端项目工程化之规范化初步总结收尾篇，如需了解，博主完整的前端项目规范化需结合“前端项目工程化之规范化代码风格 ”，“前端项目工程化之git提交规范 ”两篇文章。

提交规范

<!--注意：冒号后有空格-->
git commit -m <type>(optional scope): <description> 

<!--egg-->
git commit -m "feat(): 新增debounce函数"

备注：冒号后的空格在默认规则下必须要有，否则commit会被中断无法提交代码。

commitlint有默认的规则，也可以自定义规则，常见的规则如下：

type 类别：用于表明本次提交做了那种类型的改动。
  - feat：新增功能
  - fix：缺陷修复
  - perf：性能优化
  - refactor：重构代码(既没有新增功能，也没有修复 bug)
  - style：不影响程序逻辑的代码修改(代码风格样式等，没有改变代码逻辑)
  - docs：文档更新
  - build：项目构建系统(例如 glup，webpack，rollup 的配置等)的提交
  - revert：回滚某个更早之前的提交
  - chore：不属于以上类型的其他类型

optional scope：一个可选的修改范围。用于标识此次提交主要涉及到代码中哪个模块。

description：一句话描述此次提交的主要内容，做到言简意赅。

.commitlintrc.js 文件配置

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [
      2,
      'always',
      ['feat', 'fix', 'perf', 'refactor','style', 'docs', 'build', 'chore', 'style', 'revert']
    ],
    'type-case': [0],
    'type-empty': [0],
    'scope-empty': [0],
    'scope-case': [0],
    'subject-full-stop': [0, 'never'],
    'subject-case': [0, 'never'],
  }
}

<!-- 添加规则后提交 -->
egg：git commit -m "feat:新增debounce函数"

rules配置说明：由name和配置参数组成。

如：'type-enum': [ 2, 'always',['feat', 'fix', 'perf', 'refactor', 'docs', 'chore', 'style', 'revert']]

数组第一位为 level，可选0，1，2。

0为 disable

1为 warning

2为 error

数组第二位为应用与否，可选 always | never

数组第三位为规则的值。

总结：

本次Code Review（代码评审、代码复查或“复盘”）新收获echo命令，echo “文件内容” > 文件名即可命令行建立新文件。