因歷史遺留原因，接手的項目沒有代碼提醒/格式化，包括 eslint、pretttier，也沒有 commit 提交校驗，如 husky、commitlint、stylelint，與其期待自己或者同事的代碼寫得完美無缺，不如通過一些工具來進行規範和約束。

eslint

eslint 是一個代碼校驗工具，用來規範項目代碼風格。

初始化

通過 npm install eslint 後使用 npx eslint --init 來根據問答生成 .eslintrc.js 配置文件。我的項目是 React + JavaScript，這裏選擇了 Airbnd 的規則來校驗，不同的項目類型可以進行其它的選擇。配置詳細介紹可以參考這一篇 規範代碼編寫風格就用 eslint 和 prettier 。

生成的 .eslintrc.js 文件包含當前 eslint 配置的規則，在命令行中使用 npx eslint ./xxx.js 文件時，eslint 就會讀取項目的配置文件對其內容進行匹配，如果沒有配置文件，則會出現圖中第一次執行的命令的迴應。【Oops！Something went wrong! :( ，ESLint couldn't find a configuration file】

通過 npx eslint 可以檢測出文件不符合規範的地方，增加 --fix 參數可以自動修復部分錯誤。但我們開發的過程中也很少會通過命令檢測文件代碼是否規範，如果有一個時刻檢測代碼，當代碼出現問題標紅提示，並且 ctrl + s 保存自動格式化的工具就好了！vscode 插件來滿足你以上要求

vscode 插件

安裝【eslint】插件

並在 vscode 的 settings.json 中進行增加配置，即可享受實時校驗代碼是否符合規範，並保存後自動修復的功能。

// settings.json
 "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true,
},

prettier

prettier 也會對代碼進行格式化，和 eslint 兩者的區分在於，eslint 校驗的範圍會偏向於代碼是否優雅，比如是否存在 console 語句、是否聲明函數但未使用，而 prettier 更側重於格式，比如一行展示多少個字符，使用單引號還是雙引號。

配置

首先通過 npm install prettier 安裝依賴，然後再新增配置文件 .prettierrc.js ，在文件裏定義需要的配置，詳細字段可以參考官網。

// .prettierrc.js
module.exports = {
  printWidth: 100,
  semi: true,
  singleQuote: true,
  tabWidth: 2,
};

判斷是否生效直接使用命令 npx prettier --write [指定文件] ，查看文件是否根據 prettier 的規則格式化。

vscode 插件

同 eslint 一樣，使用 vscode 插件 prettier 來實現保存後自動格式化

在 vscode 配置文件 settings.json 中需要設置格式化的工具，默認使用 prettier 來執行。

// settings.json
"editor.defaultFormatter": "esbenp.prettier-vscode"

// 如果不生效，可能要針對每種類型的文件來執行格式化規則
"[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},

設置完之後按住 ctrl + s，自動保存為 .prettier 的文件版本，此時可能與 eslint 校驗會存在衝突，在 eslint 插件的檢查下，與 eslint 不一致的部分仍然會標紅。所以需要將 eslint 規則和 prettier 保持一致。

通過以上本地設置，可以規範自己的開發，但多人開發時難免會存在有些開發者提交的代碼不規範，那我們可以在提交時設置一個關卡，通過 git 代碼提交時的鈎子來阻擋不規範的提交。

git hooks

在網絡上找到一張 git hooks 執行流程圖示，從 git commit 開始有一些卡點，我們主要應用的鈎子是 pre-commit（通過eslint檢測下是否有報錯代碼）、commit-msg（提交的message格式是否正確）

.git/hooks

項目根目錄初始化時就會存在 .git 文件夾，其中 hooks 文件夾包含了 git 整個流程的鈎子，當前文件後綴以 .sample 結尾，去除掉 .sample 後綴並制定校驗規則會直接生效。

這裏修改了 pre-commit 的規則，為了演示直接設置校驗指定文件，正常應該是檢測使用 git add 添加到暫存區的文件，沒有通過 eslint 校驗時，則不會執行 git commit。

但我們發現，即使修改了 .git/hooks 文件夾下的文件，也不會顯示文件修改，更沒法將其添加到暫存區、本地倉庫甚至到遠程倉庫，其他同事拉取代碼後提交仍然不會有校驗。

自定義文件下的hooks

既然 .git 文件不會提交到遠程倉庫，那麼我們可以找一個代碼可以被跟蹤的地方，並且告訴 git 執行工作流的時候來我指定的文件夾執行文件。

在項目根目錄新增文件夾 .myhooks（其他的也可以），新增 pre-commit 文件，增加 eslint 的校驗，並且通過命令 git config core.hooksPath .myhooks 修改 git 執行 hooks 的地址，可進入 .git 目錄執行 cat config 查看配置是否修改。

將 .git/hooks 文件中的 .sample 後綴恢復，git commit 校驗仍然是生效的，表示我們自定義的 hooks 是成功執行的。

如果希望達到共享的目的，將 .myhooks 文件夾推送到遠程後，需要在協同開發者的筆記本都配置 git config core.hooksPath .myhooks，這一步無論是手動敲命令，還是通過工具都有些許麻煩，況且不同項目直接自定義的 hooks 文件還有可能不同，造成維護困難。

husky

針對以上問題，husky 為我們提供瞭解決方案。

配置

通過 npm install husky 以及 npx husky install 在項目根目錄生成 .husky 文件夾，將 pre-commit 文件從自定義的文件夾中移過來。

增加 package.json 的配置，在執行 npm install 之後會執行 npm run prepared ，這樣每次新增依賴時，會更新 husky。

// package.json
"script": {
  "prepared": "husky install"
}

原理

此時再執行 git commit 操作時，和前面我們看到的校驗是一致的。其實 husky 的實現原理和我們自定義 hooks 的一致，通過命令行去改變執行 git hooks 的位置。

通過 husky 可以共享 git hooks 的校驗規範，但是我們應該對哪些文件進行校驗呢？

以上為了演示方便，使用 eslint 去校驗指定文件，也可以指定文件夾，比如 src ，但這樣的校驗方式會導致我明明只修改了一個文件，卻需要去修復完src目錄下所有文件的 bug 才能提交，極大增加了開發難度。

正確的方案應該是增量檢測，只檢測使用 git add 添加到暫存區的文件，如果這部分文件有問題，修復即可提交。

lint-staged

lint-staged 就可以實現對於暫存區的檢測。

配置

使用 npm install lint-staged 安裝後，在 package.json 中配置 lint-staged 指令，因為需要使用到 eslint 和 prettier 的自動修復，所以還需要將他們添加到 script 屬性中。

// package.json
"script": {
  "eslint-fix": "eslint --fix", // 新增eslint的規則， --fix 表示自動修復
  "prettier-format": "prettier --write", // 新增eslint的規則， --write 表示自動修復
}
"lint-staged": {
    "*.{js,jsx,,ts,tsx}": [
        "npm run eslint-fix",
        "npm run prettier-format"    
    ]
}

然後在 .husky/pre-commit 將 npx eslint 修改成 npx lint-staged，再次執行 git commit 就可以 eslint 只對暫存區的文件進行校驗。

commitlint

以上是執行 commit 操作之前對於暫存區代碼進行校驗，防止不規範的代碼提交，在提交時還有一項需要注意：提交的註釋內容（git commit -m 後跟的引號中內容）是否清晰，回溯 git 提交記錄時，不清晰的描述導致排查問題、尋找功能會非常低效。

為了保證提交註釋的可閲讀性，統一使用的規範格式為 <type>: <subject>（subject前面有一個空格）。

• type 代表標識，比如：feat（新特性）、fix（修復bug）、style（樣式調整）、refactor（重構）、docs（文檔説明）
• subject 對於此時提交的描述信息

配置

以上屬於口頭規範，很有可能不被遵守，為了保證提交規範一致，還需要增加這些配置。

首先安裝提交校驗規範所需要的依賴，npm install @commitlint/cli @commitlint/config-conventional -D

新增 .commitlintrc.js 配置文件，設置 commit 備註信息的校驗方案。

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

commit-msg鈎子

再回到這張圖，commit-msg 的鈎子 是提交到本地庫之前執行的，在這個階段來校驗 commit 信息是否符合規範比較合適。

在 .husky 文件夾下新增 commit-msg 文件，增加校驗命令

#!/bin/sh
npx --no -- commitlint --edit ${1}

• npx --no ：表示只使用項目 node_modules 下的腳本，不允許找不到時下載
• commitment --edit <文件名>：執行 commitment 命令行工具，--edit 表示從文件中提取commmit內容
• $1：指向 .git/COMMIT_EDITMSG 文件，這裏存放着最後一次 commit 信息

以上便完成了對於 commit 註釋內容的校驗。我們在項目中常定義的文件類型，除了 js，還有 css ，eslint 可以對 js / jsx / vue 等文件類型進行校驗，那麼 css 也需要可以規範的工具。

stylelint

stylelint 可以完成對於 css/scss/less 等樣式表文件的校驗，功能類似於 eslint 對於 js文件。

配置

因為項目使用的樣式表為 scss 格式，所以安裝處理 scss 文件的依賴，npm install stylelint stylelint-scss stylelint-config-recommended-scss -D，注意 stylelint 需要安裝合適的版本，因為版本不正確的報錯 Error：Undefined rule annotation-no-unknow 而排查了很久。

新增 stylelintrc.js 文件，告訴 stylelint 校驗規則

module.exports = {
  extends: ['stylelint-config-recommended-scss'],
};

插件

和 eslint / prettier 相似，它也有 vscode 插件在編輯時 css/scss 文件時按住 ctrl+s 實現代碼自動格式化

vscode 需要增加一些配置

// settings.json
"editor.codeActionsOnSave": {
    "source.fixAll.stylelint": true
 },
 "stylelint.validate": ["css", "scss"],

commit

和 eslint 一樣，在提交時設置校驗避免不規範的 css 代碼提交到遠程倉庫，需要在 package.json 中增加配置。

"script": {
  "eslint-fix": "eslint --fix",
  "prettier-format": "prettier --write",
  "stylelint-fix": "stylelint --fix"  // 新增stylelint的規則， --fix 表示自動修復
}
"lint-staged": {
    "*.{js,jsx,,ts,tsx}": [
        "npm run eslint-fix",
        "npm run prettier-format"
    ],
     "*.{css,scss}":[
      "npm run stylelint-fix" // 新增 stylelint 校驗
    ]
}

stylelint 也同樣是作用於暫存區的文件，和 eslint、prettier 一樣，只是校驗不同類型的文件，所以也配置在 因為之前在 lint-staged 的規則中，在 pre-commit 文件中不需要增添新的命令。

在提交文件時就可以看到對於 css/scss 等樣式表的檢測，如果報錯會終止提交。

總結

• eslint 用來規範 js/ts/jsx 等類型文件編碼時語法
• prettier 保障 js/ts/jsx 等類型文件編碼時格式
• husky 為執行 git commit 操作設置卡點，避免不規範提交
• lint-staged 保證校驗的區域只在暫存區
• commlint 使得commit msg按照既定格式
• stylelint 確保 css/scss 類樣式表文件也能易讀統一

以上工具/插件在簡化前端開發流程，規範代碼格式上有很大的幫助，祝我們都能寫出優雅的代碼。以上就是 前端工程化之react項目統一代碼規範 相關內容，關於 前端開發，還有很多需要開發者掌握的地方，可以看看我寫的其他博文，持續更新中~