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

eslint

eslint 是一個代碼校驗工具，用來規(guī)范項目代碼風格。

初始化

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

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

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

vscode 插件

安裝【eslint】插件

并在 vscode 的 settings.json 中進行增加配置，即可享受實時校驗代碼是否符合規(guī)范，并保存后自動修復的功能。

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

prettier

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

配置

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

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

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

vscode 插件

同 eslint 一樣，使用 vscode 插件 prettier 來實現(xiàn)保存后自動格式化
[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-zo8Q3dE4-1691313614577)(en-resource://database/2230:1)]

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

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

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

git hooks

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

.git/hooks

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

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

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

自定義文件下的hooks

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

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

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

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

husky

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

配置

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

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

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

原理

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

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

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

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

lint-staged

lint-staged 就可以實現(xiàn)對于暫存區(qū)的檢測。

配置

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

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

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

commitlint

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

為了保證提交注釋的可閱讀性，統(tǒng)一使用的規(guī)范格式為 <type>: <subject>（subject前面有一個空格）。

• type 代表標識，比如：feat（新特性）、fix（修復bug）、style（樣式調(diào)整）、refactor（重構(gòu)）、docs（文檔說明）
• subject 對于此時提交的描述信息

配置

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

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

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

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

commit-msg鉤子

再回到這張圖，commit-msg 的鉤子 是提交到本地庫之前執(zhí)行的，在這個階段來校驗 commit 信息是否符合規(guī)范比較合適。

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

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

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

以上便完成了對于 commit 注釋內(nèi)容的校驗。我們在項目中常定義的文件類型，除了 js，還有 css ，eslint 可以對 js / jsx / vue 等文件類型進行校驗，那么 css 也需要可以規(guī)范的工具。

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 校驗規(guī)則

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

插件

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

vscode 需要增加一些配置

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

commit

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

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

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

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

總結(jié)

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

以上工具/插件在簡化前端開發(fā)流程，規(guī)范代碼格式上有很大的幫助，祝我們都能寫出優(yōu)雅的代碼。以上就是 前端工程化之react項目統(tǒng)一代碼規(guī)范相關內(nèi)容，關于 前端開發(fā)，還有很多需要開發(fā)者掌握的地方，可以看看我寫的其他博文，持續(xù)更新中~