vite vue3 規範化與Git Hooks

在 《JS 模組化》系列開篇中，曾提到前端技術的發展不斷融入很多後端思想，形成前端的「四個現代化」：工程化、模組化、規範化、流程化。在該系列文章中已詳細介紹了模組化的發展及四種模組化規範。本文簡單聊聊規範化中的 git 規範。

1 規範化

在企業級開發中，「一千個讀者有一千個哈姆雷特」是很常見的事，每個程式設計師對技術的理解、視角和掌握程度參差不齊，導致編寫的程式碼五花八門。規範化包括很多，我在企業實踐中重點關注兩個方面：程式碼規範 和 git 提交規範。

程式碼規範最基礎的是程式碼格式，不同的程式碼格式雖然執行起來沒有問題，但程式碼超級難看，程式碼亂七八糟、一堆 warning，雖然不影響執行，但看著太噁心，就像下面的情形：

• 估計是為了節省紙張，空格全省略，程式碼全擠在一起：

const a=b+c

const fn=()=>{}

fn(){}

for(let i=0; i<10; i++){}

• 單引號、雙引號混合使用，上一行用單引號，下一行偏要用雙引號；
• 上一行加分號，後一行省略分號；
• 定義了一些從沒有使用的變數；
• 分支判斷中只有一句話堅決不寫花括號；
• ......

我不能說上面的風格是錯誤的（寫程式碼就像玩音樂一樣，不能說絕對的對錯，只是理解不同罷了），無論怎麼寫，至少一個團隊還是應該保證統一的風格吧。於是咱們就使用了 .editorconfig 和 eslint。

.editorconfig 對編輯器的基本格式做了限制，但比較粗糙；eslint 就進行了詳細的約束。無論選擇 standard 、airbnb、prettier 任何一種，都是為了強制團隊使用統一的程式碼風格。

在 《建立 vite vue3 專案》一文中已討論瞭如何在基於 vite 的 vue3 專案中如何整合 eslint。

本文重點討論 git 提交規範。

2 git 提交規範

大家應該都是使用 git 管理程式碼吧？如果你在企業還是使用 SVN 管理程式碼，那可以趕快跑路了。git 提交程式碼使用 git commit -m '描述' 命令。但描述資訊很多情況下都是隨意填寫，git 提交規範就是針對這個描述資訊的約束。

2.1 Angular 規範

Angular 團隊規範是目前使用較多的 git 提交規範 —— 約定式提交。規範要求提交的描述資訊格式為：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

含有 optional 表示可選，故必填的內容是 type 和 description。

type 表示這次提交的型別，包括如下值：

type	含義
feat	新功能
fix	修復
docs	檔案變更
style	程式碼格式（不影響程式碼執行）
refactor	重構（不增加新功能，也不是修改 bug）
perf	效能優化
test	新增測試
chore	修改構建過程或輔助工具
revert	回退
build	打包

例如，實現了一個修改使用者列表功能，此時提交程式碼使用如下命令：

git commit -m 'feat: 實現使用者列表'

修改了 vite.config.ts 的設定，壓縮打包檔案：

git commit -m 'chore: 修改vite生產設定'

2.2 Commitizen

確定了git 提交時描述資訊的規範，那如何讓人遵守執行呢？首先需要讓開發同事知道提交資訊的內容，此時可以使用工具 commitizen 來完成。commitizen 是一個 git 提交規範化的工具，提供了 git cz 命令來代替傳統的 git commit 命令。使用 git cz 來提交程式碼，commitizen 會一步步提示輸入的欄位，並提交所填寫的必需欄位。換句話說，使用 git cz 命令，底層最後會執行 git commit，但在執行 git commit 前，會校驗描述資訊是否符合規範。如果不符合規範，則不會執行 git commit，提交失敗。

1. 全域性安裝 commitizen

yarn global add commitizen

2. 在工程中安裝 cz-conventional-changelog

yarn add cz-conventional-changelog -D

3. 在工程中初始化 commitizen 的約定式提交：

commitizen init cz-conventional-changelog --yarn --dev --exact

執行完該命令，package.json 檔案中會自動生成如下設定：

"config": {
  "commitizen": {
    "path": "./node_modules/cz-conventional-changelog"
  }
}

完成上述步驟後，便可以使用 git cz 命令來提交程式碼了。

新增需要提交的檔案，新增檔案後執行 git cz 命令，提示如下：

使用上下鍵選擇提交的型別，按照提示輸入相關內容或必填內容即可完成提交。

3 git hooks

上面實現了 Git 提交規範，但仍然有不聽話的同學會使用 git commit，如此一來提交資訊依舊是亂七八糟的，此時便需要使用 git hooks 了。

3.1 什麼是 git hooks

hooks 意思是「勾點」，也就是在執行某個操作之前或之後要做的事。git hooks 就是 git 操作的勾點，在 git 執行某個操作之前或之後要做的事，如 git 提交後、提交後、合併前、合併後、rebase前、rebase後等。在這裡需要重點關注的 git 勾點有兩個：

1. pre-commit

pre-commit 是 git commit 執行前的勾點，會在獲取提交描述資訊且提交前被呼叫，根據該勾點決定是否拒絕提交。可以在這個勾點中對程式碼進行 eslint 檢查。

2. commit-msg

commit-msg 也是 git commit 執行前的勾點，用來規範化標準格式，根據標準和提交的描述資訊決定是否拒絕提交。可以在這個勾點中檢查提價資訊是否符合規範。

3.2 commitlint 和 husky

理解 git hooks 後，就是如何在工程中引入上述勾點。此時需要使用到 husky 和 commitlint。兩者結合起來可以在提交的描述資訊不規範時會導致提交失敗，並提示錯誤。首先安裝設定 commitlint。

1. 安裝 husky 和 commitlink 相關依賴：

yarn add husky @commitlint/cli @commitlint/config-conventional -D

2. 在專案根目錄建立 commitlint.config.cjs 組態檔：

module.exports = {
  extends: [
    '@commitlint/config-conventional'
  ]
}

3. 初始化 husky

npx husky install

執行完成後，專案根目錄會自動生成一個 .husky 資料夾。

3.3 pre-commit 和 commit-msg 勾點

接下來需要使用 lint-staged 對git 暫存區（git add . 的內容）檔案進行 eslint 檢查。

1. 安裝 lint-staged

yarn add lint-staged -D

2. 在 package.json 中新增 scripts：

"scripts": {
  ...
  "lint": "eslint \"src/**/*.{js,ts,vue,jsx,tsx}\" --fix"
},

3. 在 package.json 新增 lint-staged 設定：

{
	.....
  "lint-staged": {
    "*.{js,ts,jsx,tsx,vue}": [
      "npm run lint"
    ]
  }
}

4. 分別執行下列命令，為 husky 新增 commit 前的 hook，讓其執行 eslint 和 commitlint ：

npx husky add .husky/pre-commit 'npx lint-staged'

npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'

執行完該命令後，會自動在 .husky/ 目錄下生成 pre-commi 檔案和 commit-msg 檔案。

pre-commit 檔案內容如下：

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

npx lint-staged

commit-msg 檔案內容如下：

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

npx --no-install commitlint --edit ""

3.4 測試

到此為止便完成了設定，可以按如下步驟進行測試：

git add .
git commit -m '測試提交'

控制檯會出現如下錯誤提示：

使用 git cz 命令重新提交，便可以成功提交。

各位還可以弄點 eslint 錯誤再提交試試效果。