用 husky 和 lint-staged 構(gòu)建代碼檢查工作流

前言

一個(gè)項(xiàng)目如果涉及到多人協(xié)作，由于每個(gè)人代碼的書寫習(xí)慣和風(fēng)格不太一樣，如果沒有統(tǒng)一的規(guī)范，那就會很亂，這對代碼的可維護(hù)性大大降低。

所以現(xiàn)代工程有個(gè)一環(huán)節(jié)就是代碼風(fēng)格檢查(Code Linting，下面以 Lint 簡稱)，來保障代碼規(guī)范一致性

現(xiàn)在也有很多保障代碼規(guī)范一致性，比如：ESLint、prettier、SCSSLint、JSONLint 等。比較全的可以見 github 官方的 Lint 工具列表^[1]

本文不會介紹每一個(gè)工具怎么用，而是介紹怎么把這些工具串起來，構(gòu)建一個(gè)代碼檢查的工作流。

最簡單的方法

最簡單的方法就是自己每次在 commit 代碼之前先處理一下，以 eslint 舉例：

eslint?src/**/*.js

git?add?.

git?commit?-m?'feat:?一個(gè)新?feature'

這種方法有兩個(gè)致命的缺點(diǎn)：

1. 如果檢測工具多，需要多次處理。
2. 很容易遺忘。

通過 scripts 來解決如果檢測工具多，需要多次處理

scripts 就是 package.json 里的 scripts。

比如你同時(shí)需要用到 prettier 和 eslint，可以定制一個(gè)腳本，然后運(yùn)行這個(gè)腳本之后再提交代碼：

{
??"scripts":?{
?????"lint":?"prettier?--write?&?eslint?src/**/*.js"
??}
}

然后每次提交代碼前就只需要：

npm?run?lint

git?add?.

git?commit?-m?'feat:?一個(gè)新?feature'

通過 husky(哈士奇)來解決容易遺忘的問題

雖然咱們通過 scripts 來解決檢查工具多的問題，但是還有一個(gè)容易遺忘怎么解呢？

解決方案就是通過 husky，原理實(shí)際上是通過 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].

”

這個(gè)是 husky 官網(wǎng)的一句話，用來描述 husky 可以做什么。

那到底怎么解決呢？接下來介紹一下 husky 的使用方式：

1. 安裝

1. 安裝 husky

npm?install?husky?--save-dev

2. 啟用 git hooks

npx?husky?install

執(zhí)行完之后文件根目錄會多一個(gè) .husky 文件夾：

3. 在安裝后自動啟用 git hooks

npm?set-script?prepare?"husky?install"

然后你可以看到 package.json 里增加一個(gè) script

//?package.json
{
??"scripts":?{
????"prepare":?"husky?install"
??}
}

“

注意一個(gè)點(diǎn)：yarn 安裝是不支持 prepare 這個(gè)生命周期的，需要將 prepare 改成 postinstall。具體可以見官網(wǎng)^[4]

”

2. 創(chuàng)建一個(gè) precommit hook

npx?husky?add?.husky/pre-commit?"npm?run?lint"

git?add?.husky/pre-commit

執(zhí)行完之后在 .husky 目錄下會多一個(gè) pre-commit 的文件，里面的 npm run lint 就是這個(gè) hook 要執(zhí)行的命令，后續(xù)要改也可以直接改這個(gè)文件。

這個(gè)時(shí)候 commit 就會先自動執(zhí)行 npm run lint 了，然后才會 commit。

但是這樣解決了以上的問題，當(dāng)項(xiàng)目大的時(shí)候會遇到一些問題，比如每次 lint 是整個(gè)項(xiàng)目的文件，文件太多導(dǎo)致跑的時(shí)間過久，另外如果這個(gè) lint 是在項(xiàng)目后期接入的話，可能 lint 命令會報(bào)很多錯(cuò)誤，全量去改可能會有問題。

lint-stadge 只 lint 改動的

基于上面的痛點(diǎn)，lint-stadge 就出現(xiàn)了，它的解決方案就是只檢查本次提交所修改(指 git 暫存區(qū)^[5]里的東西)的問題，這樣每次 lint 量就比較小，而且是符合我們的需求的。

“

如果不知道暫存區(qū)的需要去復(fù)習(xí)一下 git 知識，簡單來說就是 git add 或者 git commit -a 的那部分代碼會先放到暫存區(qū)。

”

lint-staged 用法如下：

1. 安裝

npm?install?-D?lint-staged

2. 修改 package.json 配置

{
???"lint-staged":?{
?"src/**/*.js":?"npm?run?lint"
???}
}

3. 設(shè)置 precommit 為運(yùn)行 lint-staged

在完成上面的配置之后，可以手動通過 npx lint-staged 來檢查暫存區(qū)里面的文件。

手動是永遠(yuǎn)不會手動的，自動的方法就是將 npx lint-staged ? 設(shè)置到 hook 里。

npx?husky?add?.husky/pre-commit?"npx?lint-staged"

或者直接去改 .husky 下面 precommit 的文件。

到現(xiàn)在我們的代碼檢查工作流就完成了。在 git commit 的時(shí)候就自動的回去幫我們跑檢查腳本，而且還是只針對我們本次提交的代碼進(jìn)行檢查。

參考配置

react + less 項(xiàng)目 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"
????]
???}
}

總結(jié)

本文筆者沒有去詳細(xì)介紹每個(gè) lint 工具的使用和配置，也沒有直接給一個(gè)構(gòu)建代碼檢查工作流的最佳實(shí)踐，而是一步一步從最原始到使用 git hooks、husky、lint-staged 各種工具來推導(dǎo)出最后的方案。

因?yàn)槲矣X得如果不把每個(gè)工具用來解決什么問題，為什么需要它說清楚，而是直接給一個(gè)最佳實(shí)踐的 SOP，這樣會成為一個(gè)無腦 copy 的執(zhí)行者，當(dāng)哪天找不到這篇文章的時(shí)候自己可能無從下手了，但是當(dāng)你知道了自己遇到什么問題，應(yīng)該怎么去解決之后，自己也可以從 0 配置一份出來。

參考

• 用 husky 和 lint-staged 構(gòu)建超溜的代碼檢查工作流^[6]
• husky 官網(wǎng)^[7]

參考資料