因歷史遺留原因，接手的項(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)目的配置文件對其內(nèi)容進(jìn)行匹配，如果沒有配置文件，則會(huì)出現(xiàn)圖中第一次執(zhí)行的命令的回應(yīng)?！綩ops！Something went wrong! ?? ，ESLint couldn't find a configuration file】
通過 npx eslint 可以檢測出文件不符合規(guī)范的地方，增加 --fix 參數(shù)可以自動(dòng)修復(fù)部分錯(cuò)誤。但我們開發(fā)的過程中也很少會(huì)通過命令檢測文件代碼是否規(guī)范，如果有一個(gè)時(shí)刻檢測代碼，當(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ì)對代碼進(jìn)行格式化，和 eslint 兩者的區(qū)分在于，eslint 校驗(yàn)的范圍會(huì)偏向于代碼是否優(yōu)雅，比如是否存在 console 語句、是否聲明函數(shù)但未使用，而 prettier 更側(cè)重于格式，比如一行展示多少個(gè)字符，使用單引號還是雙引號。
配置
首先通過 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)格式化
在 vscode 配置文件 settings.json 中需要設(shè)置格式化的工具，默認(rèn)使用 prettier 來執(zhí)行。
// settings.json
"editor.defaultFormatter": "esbenp.prettier-vscode"
// 如果不生效，可能要針對每種類型的文件來執(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檢測下是否有報(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)該是檢測使用 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
針對以上問題，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)該對哪些文件進(jìn)行校驗(yàn)?zāi)兀?/p>
以上為了演示方便，使用 eslint 去校驗(yàn)指定文件，也可以指定文件夾，比如 src ，但這樣的校驗(yàn)方式會(huì)導(dǎo)致我明明只修改了一個(gè)文件，卻需要去修復(fù)完src目錄下所有文件的 bug 才能提交，極大增加了開發(fā)難度。
正確的方案應(yīng)該是增量檢測，只檢測使用 git add 添加到暫存區(qū)的文件，如果這部分文件有問題，修復(fù)即可提交。
lint-staged
lint-staged 就可以實(shí)現(xiàn)對于暫存區(qū)的檢測。
配置
使用 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 只對暫存區(qū)的文件進(jìn)行校驗(yàn)。
commitlint
以上是執(zhí)行 commit 操作之前對于暫存區(qū)代碼進(jìn)行校驗(yàn)，防止不規(guī)范的代碼提交，在提交時(shí)還有一項(xiàng)需要注意：提交的注釋內(nèi)容（git commit -m 后跟的引號中內(nèi)容）是否清晰，回溯 git 提交記錄時(shí)，不清晰的描述導(dǎo)致排查問題、尋找功能會(huì)非常低效。
為了保證提交注釋的可閱讀性，統(tǒng)一使用的規(guī)范格式為 <type>: <subject>（subject前面有一個(gè)空格）。
- type 代表標(biāo)識，比如：feat（新特性）、fix（修復(fù)bug）、style（樣式調(diào)整）、refactor（重構(gòu)）、docs（文檔說明）
- subject 對于此時(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 信息
以上便完成了對于 commit 注釋內(nèi)容的校驗(yàn)。我們在項(xiàng)目中常定義的文件類型，除了 js，還有 css ，eslint 可以對 js / jsx / vue 等文件類型進(jìn)行校驗(yàn)，那么 css 也需要可以規(guī)范的工具。
stylelint
stylelint 可以完成對于 css/scss/less 等樣式表文件的校驗(yàn)，功能類似于 eslint 對于 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í)就可以看到對于 css/scss 等樣式表的檢測，如果報(bào)錯(cuò)會(huì)終止提交。
文章來源：http://www.zghlxwxcb.cn/news/detail-628895.html
總結(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)一
以上工具/插件在簡化前端開發(fā)流程，規(guī)范代碼格式上有很大的幫助，祝我們都能寫出優(yōu)雅的代碼。以上就是 前端工程化之react項(xiàng)目統(tǒng)一代碼規(guī)范 相關(guān)內(nèi)容，關(guān)于 前端開發(fā)，還有很多需要開發(fā)者掌握的地方，可以看看我寫的其他博文，持續(xù)更新中~文章來源地址http://www.zghlxwxcb.cn/news/detail-628895.html
到了這里，關(guān)于為react項(xiàng)目添加開發(fā)/提交規(guī)范（前端工程化、eslint、prettier、husky、commitlint、stylelint）的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
