用 Husky和Iint-Staged 構建代碼檢查工作流
前言
一個項目如果涉及到多人協作，由于每個人代碼的書寫習慣和風格不太一樣，如果沒有統一的規范，那就會很亂，這對代碼的可維護性大大降低。
所以現代工程有個一環節就是代碼風格檢查(Code Linting，下面以 Lint 簡稱)，來保障代碼規范一致性
現在也有很多保障代碼規范一致性，比如：ESLint、prettier、SCSSLint、JSONLint 等。比較全的可以見 github 官方的 Lint 工具列表[1]
本文不會介紹每一個工具怎么用，而是介紹怎么把這些工具串起來，構建一個代碼檢查的工作流。
最簡單的方法
最簡單的方法就是自己每次在 commit 代碼之前先處理一下，以 eslint 舉例：
eslint src/**/*.js
git add .
git commit -m 'feat: 一個新 feature'
這種方法有兩個致命的缺點：
- 如果檢測工具多，需要多次處理。
- 很容易遺忘。
通過 scripts 來解決如果檢測工具多，需要多次處理scripts 就是 package.json 里的 scripts。
比如你同時需要用到 prettier 和 eslint，可以定制一個腳本，然后運行這個腳本之后再提交代碼：
{
"scripts": {
"lint": "prettier --write & eslint src/**/*.js"
}
}
然后每次提交代碼前就只需要：
npm run lint
git add .
git commit -m 'feat: 一個新 feature'
通過 husky(哈士奇)來解決容易遺忘的問題
雖然咱們通過 scripts 來解決檢查工具多的問題，但是還有一個容易遺忘怎么解呢?
解決方案就是通過 husky，原理實際上是通過 git hooks[2] 來解決，husky 就是讓 git hooks 用起來更容易的工具。
You can use it to lint your commit messages , run tests , lint code , etc... when you commit or push. Husky supports all Git hooks[3].
”這個是 husky 官網的一句話，用來描述 husky 可以做什么。
那到底怎么解決呢?接下來介紹一下 husky 的使用方式：
1. 安裝
安裝 husky
npm install husky --save-dev
啟用 git hooks
npx husky install
執行完之后文件根目錄會多一個 .husky 文件夾：
在安裝后自動啟用 git hooks
npm set-script prepare "husky install"
然后你可以看到 package.json 里增加一個 script
// package.json
{
"scripts": {
"prepare": "husky install"
}
}
注意一個點：yarn 安裝是不支持 prepare 這個生命周期的，需要將 prepare 改成 postinstall。具體可以見官網[4]
2. 創建一個 precommit hook
npx husky add .husky/pre-commit "npm run lint"
git add .husky/pre-commit
執行完之后在 .husky 目錄下會多一個 pre-commit 的文件，里面的 npm run lint 就是這個 hook 要執行的命令，后續要改也可以直接改這個文件。
這個時候 commit 就會先自動執行 npm run lint 了，然后才會 commit。
但是這樣解決了以上的問題，當項目大的時候會遇到一些問題，比如每次 lint 是整個項目的文件，文件太多導致跑的時間過久，另外如果這個 lint 是在項目后期接入的話，可能 lint 命令會報很多錯誤，全量去改可能會有問題。
lint-stadge 只 lint 改動的
基于上面的痛點，lint-stadge 就出現了，它的解決方案就是只檢查本次提交所修改(指 git 暫存區[5]里的東西)的問題，這樣每次 lint 量就比較小，而且是符合我們的需求的。
如果不知道暫存區的需要去復習一下 git 知識，簡單來說就是 git add 或者 git commit -a 的那部分代碼會先放到暫存區。
lint-staged 用法如下：
1. 安裝
npm install -D lint-staged
2. 修改 package.json 配置
{
"lint-staged": {
"src/**/*.js": "npm run lint"
}
}
3. 設置 precommit 為運行 lint-staged
在完成上面的配置之后，可以手動通過 npx lint-staged 來檢查暫存區里面的文件。
手動是永遠不會手動的，自動的方法就是將 npx lint-staged 設置到 hook 里。
npx husky add .husky/pre-commit "npx lint-staged"
或者直接去改 .husky 下面 precommit 的文件。
到現在我們的代碼檢查工作流就完成了。在 git commit 的時候就自動的回去幫我們跑檢查腳本，而且還是只針對我們本次提交的代碼進行檢查。
參考配置
react + less 項目 lint-staged 的配置可以參考：
{
"lint-staged": {
"**/*.less": "stylelint --syntax less",
"**/*.{js,jsx,ts,tsx}": "eslint --ext .js,.jsx,.ts,.tsx",
"**/*.{js,jsx,tsx,ts,less,md,json}": [
"prettier --write",
"git add"
]
}
}
總結
本文筆者沒有去詳細介紹每個 lint 工具的使用和配置，也沒有直接給一個構建代碼檢查工作流的最佳實踐，而是一步一步從最原始到使用 git hooks、husky、lint-staged 各種工具來推導出最后的方案。
因為我覺得如果不把每個工具用來解決什么問題，為什么需要它說清楚，而是直接給一個最佳實踐的 SOP，這樣會成為一個無腦 copy 的執行者，當哪天找不到這篇文章的時候自己可能無從下手了，但是當你知道了自己遇到什么問題，應該怎么去解決之后，自己也可以從 0 配置一份出來。
參考
- 用 husky 和 lint-staged 構建超溜的代碼檢查工作流[6]
- husky 官網[7]
參考資料
[1]Lint 工具列表:
??https://github.com/collections/clean-code-linters??
[2]git hooks:
??https://git-scm.com/book/zh/v2/%E8%87%AA%E5%AE%9A%E4%B9%89-Git-Git-%E9%92%A9%E5%AD%90??
[3]all Git hooks:
??https://git-scm.com/docs/githooks??
[4]官網:
??https://typicode.github.io/husky/#/?id=yarn-2??
[5]git 暫存區:
??https://www.4e00.com/git-zh/1-introduction.html#-ReHMS4ux??
[6]用 husky 和 lint-staged 構建超溜的代碼檢查工作流:
??https://segmentfault.com/a/1190000009546913??
[7]husky 官網:
