用魔法打敗魔法：前端程式碼規範化

2021 年 7 月 23 日
筆記
commitizen, eslint, husky

早幾年接手過一個項目，一堆bug不說，程式碼還又臭又長，據說之前寫程式碼的那位仁兄經常改一個bug又帶出十個bug🌝項目里充斥著各種含義不明的變數、沒有用到的不知道從哪裡複製粘貼過來的函數、亂七八糟的console、隨心所欲的空行和毫無意義的注釋……

很多程式設計師沒有程式碼規範意識，經常覺得只要功能能用就行了，程式碼規範浪費時間，於是寫出來的程式碼過一段時間可能連自己都看不懂是坨什麼東西，更不用說接手的同事了。

今日便來說說，如何從技術層面，實現程式碼規範以及程式碼提交規範。

1、工具簡介

husky：一個Git hooks工具，可以讓我們在git提交前後進行一些操作，比如，在提交之前檢查程式碼是否規範、進行統一的格式化處理、檢查git提交的資訊格式等等；
eslint：一個用NodeJS寫的Javascript程式碼檢查工具，可自定義規則；
lint-staged：一個能夠只對git變更文件進行程式碼檢查的工具；
commitizen：一個提供了互動式命令，可用於規範git commit資訊的工具。

以上就是我們這次要用到的四個工具。

2、實現思路

我們可以通過husky提供的鉤子(hooks)：

在git提交前，使用eslint或者lint-staged對程式碼進行檢查，並進行統一的格式化處理；
在git提交時，檢查git commit的格式是否符合規定；同時，使用commitizen實現命令行交互，來輔助我們生成合規的git commit。

3、具體實現

3.1 husky

安裝：

yarn add husky -D

在package.json的script中添加：

"scripts": {
  "prepare": "husky install"
}

prepare是npm的生命周期腳本。

當執行npm install的時候，就會自動執行腳本內容husky install，從而在當前項目的根目錄下生成.husky文件夾。

這裡的husky.sh配置主要是為了獲取hook的執行結果，當執行過程中出錯時，就退出進程。

接下來就可以愉快地使用git hooks啦。

3.2 hook：pre-commit

命令行執行yarn husky add .husky/pre-commit生成pre-commit腳本（當然也可以手動）：

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

undefined

稍作修改，來驗證下在git commit的時候是否執行了這個腳本：

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

echo "commit之前執行"

命令行git提交程式碼：

git add .
git commit -m」add husky config」

可以看到pre-commit腳本執行成功，列印出了語句。

3.3 在pre-commit里添加eslint檢查

安裝：

yarn add eslint —dev

安裝完成後，執行

yarn run eslint —init

或

./node_modules/.bin/eslint —init

執行完成後會自動在根目錄生成eslint配置文件.eslinttrc.js。

修改pre-commit，添加eslint格式檢查：

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"


echo "eslint格式校驗" && ./node_modules/.bin/eslint src/*

可以看到，eslint檢測出程式碼里有2個error和1個warning。

error是必須修改的，可以使用eslint --fix自動修復，並執行git add .把fix後的變更也添加到git快取區：

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

echo "eslint格式校驗"

./node_modules/.bin/eslint src/* --fix # 對src下的所有文件作eslint檢查，並用--fix修復error

git add . # 將eslint的fix內容也添加到git提交中

測試一下：

成功！

提示：如果使用的是Github Desktop這類的圖形工具，有可能會出現下面這個錯誤——

這是因為我們只在項目里安裝了eslint，當在軟體上運行的時候就有可能出現路徑錯誤，只需要全局安裝一下eslint就可以了：

yarn add eslint -g

上面的eslint檢查腳本會對src中的所有文件進行檢查。如果是一個新項目還好，如果是一些老項目，那麼涉及到的變更文件就會很多。

如果不想每次都全量檢測，那麼可以通過git diff來獲取到變更的文件：

修改pre-commit：

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

echo "eslint格式校驗"

arr=`git diff --name-only  HEAD` # 查看變更文件
for filepath in ${arr[@]}
do
    if [[ "$filepath" =~ ^[src/] ]]; then : # 只檢測src下被修改的文件的格式
        if [ -f "$filepath" ];then # 只對存在的文件進行fix，跳過delete的文件
            echo $filepath
            ./node_modules/.bin/eslint $filepath --fix
            git add $filepath
        fi
    fi
done

這段程式碼實現了：只對src中有變更且非刪除的文件進行eslint檢查和fix。

這裡推薦一個工具，也就是上面提到的lint-staged，也能實現同樣的功能，使用起來更簡單。

執行npx mrm@2 lint-staged，可以看到package.json中多了關於lint-staged的配置：

修改一下：

"lint-staged": {
    "src/*": "eslint --fix"
}

pre-commit改為：

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

echo "eslint格式校驗"

npx lint-staged

測試一下：

成功！

至此，我們就實現了基本的程式碼規範配置。

eslint的詳細配置參數這裡就不展開了，感興趣的同學可以去官網上自行探索。

3.4 用commitizen規範git commit

安裝：

npm install --save-dev commitizen

在package.json中配置：

  "scripts": {
    "commit": "cz"
  },
  "config": {
    "commitizen": {
      "path": "cz-conventional-changelog"
    }
  }

測試一下：

注意，這裡就不能用git commit了，而要用yarn run commit或npm run commit，執行後命令行里會出現一些交互選項，來幫助我們生成git commit。

看不習慣英文的也可以安裝中文包：

yarn add cz-conventional-changelog-zh

commitizen只能幫助我們生成規範的git commit，如果有些隊友忘了使用yarn run commit，而直接用git commit -m」xxx」寫了不規範的提交資訊，怎麼辦？

還記得上面說的husky嗎？我們可以通過husky的commit-msg鉤子來校驗git commit的提交資訊。

3.5 hook：commit-msg

yarn husky add .husky/commit-msg

修改commit-msg：

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"


commit_regex='^Merge.+|(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert|types)(\(.+\))?: .{1,50}'


if ! grep -iqE "$commit_regex" "$1"; then

echo
echo "commit資訊格式錯誤！！"

echo "格式應為：[Type]: [Summary]"

echo "Type可選值為Merge|feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert|types"

echo "注意中間的空格"

echo "示例：git commit -m \"test: add something test\""

echo
exit 1

fi

測試一下：

大功告成！

4、總結

規範的程式碼不僅能減少合併衝突，還有助於提高程式碼的可讀性，降低之後的維護成本。

對團隊而言，有可能是鐵打的程式碼流水的程式設計師，前人留下的坑得後人去填，規範程式碼是非常必要的。

對個人而言，規範的程式碼不僅能減少bug的出現，還有助於更好地理解程式語言的特性，成長有時候就是這些細節處的積累。

技術上只能起到一部分的規範作用，更重要的還是意識上的主觀能動性，只有意識到程式碼規範的重要性，才能真正實現項目的程式碼規範化。

附錄

Tags: commitizen eslint husky