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

eslint

eslint 是一個(gè)代碼校驗(yàn)工具，用來規(guī)范項(xiàng)目代碼風(fēng)格。

初始化

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

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

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

vscode 插件

安裝【eslint】插件

并在 vscode 的 settings.json 中進(jìn)行增加配置，即可享受實(shí)時(shí)校驗(yàn)代碼是否符合規(guī)范，并保存后自動(dòng)修復(fù)的功能。

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

prettier

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

配置

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

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

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

vscode 插件

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

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

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

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

git hooks

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

.git/hooks

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

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

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

自定義文件下的hooks

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

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

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

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

husky

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

配置

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

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

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

原理

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

通過 husky 可以共享 git hooks 的校驗(yàn)規(guī)范，但是我們應(yīng)該對(duì)哪些文件進(jìn)行校驗(yàn)?zāi)?#xff1f;

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

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

lint-staged

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

配置

使用 npm install lint-staged安裝后，在 package.json 中配置 lint-staged 指令，因?yàn)樾枰褂玫?eslint 和 prettier 的自動(dòng)修復(fù)，所以還需要將他們添加到 script 屬性中。

// package.json
"script": {"eslint-fix": "eslint --fix", // 新增eslint的規(guī)則， --fix 表示自動(dòng)修復(fù)"prettier-format": "prettier --write", // 新增eslint的規(guī)則， --write 表示自動(dòng)修復(fù)
}
"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 只對(duì)暫存區(qū)的文件進(jìn)行校驗(yàn)。

commitlint

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

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

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

配置

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

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

新增 .commitlintrc.js 配置文件，設(shè)置 commit 備注信息的校驗(yàn)方案。

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

commit-msg鉤子

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

在 .husky 文件夾下新增 commit-msg 文件，增加校驗(yàn)命令

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

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

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

stylelint

stylelint 可以完成對(duì)于 css/scss/less 等樣式表文件的校驗(yàn)，功能類似于 eslint 對(duì)于 js文件。

配置

因?yàn)轫?xiàng)目使用的樣式表為 scss 格式，所以安裝處理 scss 文件的依賴，npm install stylelint stylelint-scss stylelint-config-recommended-scss -D，注意 stylelint 需要安裝合適的版本，因?yàn)榘姹静徽_的報(bào)錯(cuò) Error：Undefined rule annotation-no-unknow 而排查了很久。

新增 stylelintrc.js 文件，告訴 stylelint 校驗(yàn)規(guī)則

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

插件

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

vscode 需要增加一些配置

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

commit

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

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

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

在提交文件時(shí)就可以看到對(duì)于 css/scss 等樣式表的檢測(cè)，如果報(bào)錯(cuò)會(huì)終止提交。

總結(jié)

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

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