vite vue3 規範化與Git Hooks

2022 年 10 月 14 日
筆記
git, vite, VUE

在《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，提交失敗。

全局安裝 commitizen

yarn global add commitizen

在工程中安裝 cz-conventional-changelog

yarn add cz-conventional-changelog -D

在工程中初始化 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 鉤子有兩個：

pre-commit

pre-commit 是 git commit 執行前的鉤子，會在獲取提交描述信息且提交前被調用，根據該鉤子決定是否拒絕提交。可以在這個鉤子中對代碼進行 eslint 檢查。

commit-msg

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

3.2 commitlint 和 husky

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

安裝 husky 和 commitlink 相關依賴：

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

在項目根目錄創建 commitlint.config.cjs 配置文件：

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

初始化 husky

npx husky install

執行完成後，項目根目錄會自動生成一個 .husky 文件夾。

3.3 pre-commit 和 commit-msg 鉤子

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

安裝 lint-staged

yarn add lint-staged -D

在 package.json 中添加 scripts：

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

在 package.json 添加 lint-staged 配置：

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

分別執行下列命令，為 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 錯誤再提交試試效果。

Tags: git vite VUE