使用husky + lint-staged助力團隊編碼規範

使用husky + lint-staged助力團隊編碼規範

• 寫在前面
• 瞭解 githooks
• husky
• 鉤子中執行多個命令
• hook 攔截
• lint-staged
• mrm
• 關於 prettier 的問題

寫在前面

husky 是一個爲 git 客戶端增長 hook 的工具。安裝後，它會自動在倉庫中的 .git/ 目錄下增長相應的鉤子；好比 pre-commit 鉤子就會在你執行 git commit 的觸發。

那麼咱們能夠在 pre-commit 中實現一些好比 lint 檢查、單元測試、代碼美化等操做。固然，pre-commit 階段執行的命令固然要保證其速度不要太慢，每次 commit 都等好久也不是什麼好的體驗。

lint-staged，一個僅僅過濾出 Git 代碼暫存區文件(被 git add 的文件)的工具；這個很實用，由於咱們若是對整個項目的代碼作一個檢查，可能耗時很長，若是是老項目，要對以前的代碼作一個代碼規範檢查並修改的話，這可能就麻煩了呀，可能致使項目改動很大。

因此這個 lint-staged，對團隊項目和開源項目來講，是一個很好的工具，它是對我的要提交的代碼的一個規範和約束。

瞭解 githooks

Git Hooks 就是在 Git 執行特定事件（如commit、push、receive等）時觸發運行的腳本，相似於「鉤子函數」，沒有設置可執行的鉤子將被忽略。

在項目的 .git/hooks 目錄中，有一些 .sample 結尾的鉤子示例腳本，若是想啓用對應的鉤子，只需手動刪除後綴，便可。（刪除某一個 hook 的後綴 .sample 便可啓用該 hook 腳本，默認是不啓用的。）

【可是，咱們通常不去改動 .git/hooks 裏面的文件，由於咱們使用 husky 】

husky

• husky 的安裝

npm i husky -D --registry=https://registry.npm.taobao.org

husky 在安裝過程當中會在 .git/hooks 文件夾中生成一系列的 git hook 腳本。

須要注意的是：你要留意 husky 的安裝信息，是否爲你安裝了 git 鉤子。

若是安裝正確的話，能夠看到 husky 會打印出以下消息：

> node husky install
husky > setting up git hooks  
husky > done

但也有可能：

這個就是因爲電腦 node 版本的緣由，跳過了 Git 鉤子安裝，至關因而沒有安裝成功哦~

OK，假設你的 husky 安裝是正常的，那麼 husky 爲你安裝的 hooks 將會生效。這樣咱們在 git commit 的時候會觸發 pre-commit 鉤子從而觸發到 huksy。

咱們在 package.json 文件中配置 husky 的鉤子須要執行的 命令 或 操做。

"husky": {
  "hooks": {
    "pre-commit": "echo \"git commit trigger husky pre-commit hook\" "
  }
}

這樣，在 git commit 的時候就會看到 pre-commit 執行了。

從 1.0.0 開始，husky 的配置可使用 .huskyrc、.huskyrc.json、.huskyrc.js 或 husky.config.js 文件

鉤子中執行多個命令

• 根據 npm script 的規則，使用 &&

"husky": {
  "hooks": {
    "pre-commit": "echo \"git commit trigger husky pre-commit hook\" && npm run test"
  }
}

• 若是您更喜歡使用數組，建議的方法是在 .huskyrc.js 中定義它們

const tasks = arr => arr.join(' && ')

module.exports = {
  'hooks': {
    'pre-commit': tasks([
      'npm run lint',
      'npm run test'
    ])
  }
}

hook 攔截

爲了阻止提交，pre-commit 腳本必須以非零的退出代碼退出。

若是您的提交未被阻止，請檢查腳本退出代碼。

固然 husky 不止能驗證 commit ，也能夠進行 push 等其餘操做驗證，這裏就不一一舉例了，具體能夠參照 npm husky 。

---

lint-staged

lint-staged 是一個在 git 暫存文件上（也就是被 git add 的文件）運行已配置的 linter（或其餘）任務。lint-staged 老是將全部暫存文件的列表傳遞給任務。

// package.json

"lint-staged": {
  "src/**/*.{js,vue}": [
    "prettier --write",
    "eslint --cache --fix",
    "git add"
  ]
}

這裏 lint-staged 的配置是：在 git 的待提交的文件中，在 src 目錄下的全部 .js .vue 都要執行三條命令。前兩條一下子說，後一條是將處理過的代碼從新 add 到 git 中。

結合咱們前面介紹的 husky，配合 husky 的 pre-commit 鉤子，將會造成一個自動化工具鏈。

"husky": {
  "hooks": {
    "pre-commit": "lint-staged"
  }
},
"lint-staged": {
  "src/**/*.{js,vue}": ["prettier --write", "eslint --cache --fix", "git add"]
}

在 commit 以前，將暫存區的內容作一次 代碼檢查 和 代碼美化，而後再添加到暫存區；而後再 commit，完美！！

從 v3.1 開始，您如今可使用不一樣的方式進行 lint-staged 配置：

• lint-staged 在你的對象 package.json
• .lintstagedrc JSON或YML格式的文件
• lint-staged.config.js JS格式的文件
• 使用 --config 或 -c 標誌傳遞配置文件

mrm

mrm 是一個自動化工具。推薦

它將根據 package.json 依賴項中的代碼質量工具來安裝和配置 husky 和 lint-staged，所以請確保在此以前安裝並配置全部代碼質量工具，如 Prettier 和 ESlint

安裝 mrm 並執行 lint-staged 任務：

npm i mrm -D --registry=https://registry.npm.taobao.org
npx mrm lint-staged

此時，將會自動給你安裝相關依賴工具，以及相關配置文件。

mrm 文檔、mrm api doc

關於 prettier 的問題

prettier 是一個很好的格式化代碼的插件，但對已經有必定迭代完成度的代碼不推薦使用。使用該插件後，它會將原有的代碼也進行格式化，形成不少不可知的問題，我就是前車可鑑，使用 prettier 後，本來已經沒有 eslint 問題的代碼，又多出了更多的不知道什麼緣由的報錯，只能將代碼回退處理。

因此，這也就是咱們爲何在 lint-staged 中，執行 prettier 的緣由。

-----------------(正文完)------------------

前端學習交流羣，想進來面基的，能夠加羣：

或者手動search羣號：685486827，832485817；

寫在最後： 約定優於配置 —— 軟件開發的簡約原則
-------------------------------- (完)--------------------------------------

個人：
我的網站： https://neveryu.github.io/neveryu/
Github： https://github.com/Neveryu
新浪微博： https://weibo.com/Neveryu

更多學習資源請關注個人新浪微博…