前端代碼風(fēng)格自動化系列（二）之Commitlint

FuisonDesign 發(fā)布于2019-08-23 14:33 / 2847人閱讀

摘要：文件配置配置說明由和配置數(shù)組組成，如，數(shù)組中第一位為，可選，為，為，為，第二位為應(yīng)用與否，可選，第三位該的值。

在有了Husky賦能之后，我們有能力在Git的鉤子里做一些事情，首先不得不提的是代碼的提交規(guī)范和規(guī)范的校驗，優(yōu)雅的提交，方便團隊協(xié)作和快速定位問題。首推Commitlint，另外@加神推薦了Gitmoji也是一個很有意思的工具。

安裝

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

// 生成配置文件commitlint.config.js，當然也可以是 .commitlintrc.js
echo "module.exports = {extends: ["@commitlint/config-conventional"]};" > commitlint.config.js

配置

在husky的配置加入CommitlIint配置，v1.0.1版本以后為HUSKY_GIT_PARAMS，v0.14.3為GIT_PARAMS

"husky": {
    "hooks": {
      "pre-commit": "npm run test",
      "commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"
    }
  },

定制提交規(guī)范 提交格式（注意冒號后面有空格）

常用的type類別

upd：更新某功能（不是 feat, 不是 fix）

feat：新功能（feature）

fix：修補bug

docs：文檔（documentation）

style：格式（不影響代碼運行的變動）

refactor：重構(gòu)（即不是新增功能，也不是修改bug的代碼變動）

test：增加測試

chore：構(gòu)建過程或輔助工具的變動

例子：

git commit -m "feat: 增加 xxx 功能"
git commit -m "bug: 修復(fù) xxx 功能"

subject

subject是 commit 目的的簡短描述，可以做一些配置，如最大長度限制。

commitlint.config.js文件配置

rule配置說明:：rule由name和配置數(shù)組組成，如："name:[0, "always", 72]"，數(shù)組中第一位為level，可選0,1,2，0為disable，1為warning，2為error，第二位為應(yīng)用與否，可選always|never，第三位該rule的值。具體配置例子如下：

module.exports = {
  extends: [
    "@commitlint/config-conventional"
  ],
  rules: {
    "type-enum": [2, "always", [
      "upd", "feat", "fix", "refactor", "docs", "chore", "style", "revert"
     ]],
    "type-case": [0],
    "type-empty": [0],
    "scope-empty": [0],
    "scope-case": [0],
    "subject-full-stop": [0, "never"],
    "subject-case": [0, "never"],
    "header-max-length": [0, "always", 72]
  }
};

這里列出了大部分常用的配置，其它的可以參考Commitlint網(wǎng)站，具體使用例子：

這里我們使用錯誤的提交方式，最上面的是自動測試的腳本，大家可以忽略，husky給出了commit-msg的input為xxx，觸發(fā)了subject-empty，type-empty兩個規(guī)則，提交不符合規(guī)范，被攔了下來。如果是正確的提交，例子如下：

關(guān)于Commitlint的使用就到這里了。