一、問題闡述:為什么要使用 Eslint+prettier 自動格式化代碼?
現在前端的項目越來越大,項目中每個人都有自己習慣使用的編輯器,每個人的編碼風格也不相同,導致后期代碼 review 和項目維護難度較大
1、借助 husky 在代碼 commit 的時候使用,使用prettier進行代碼格式化,Eslint(也可以進行代碼格式化的規范)進行代碼自動補全或修復
2、開發者不用關心編寫的過程,只需要在提交代碼的時候關注下commit的結果,但是有些時候 Eslint 可能無法修復,我們可以根據錯誤提示進行手動修復,平時編寫代碼只要注意編碼規范,一般問題不大
1、前期依賴包安裝:husky、eslint、lint-staged、prettier
yarn add husky eslint lint-staged prettier --dev
或
npm install husky eslint lint-staged prettier -D
2、根據 git 提交過程進行配置的思路
提交代碼時需要借助 git 提供的鉤子對代碼進行檢測 — husky 配置
提交之前要先進行代碼格式化 — prettier 配置
對于不規范的代碼進行修復 — Eslint 配置
對于 Eslint 修復不了的代碼 commit 會失敗并給出提示 — “git add” 配置
上述四點需要在 package.json 內部進行配置,如下:
// package.json
{
? ...
"husky": {
"hooks": {
"pre-commit":"lint-staged"
? ? }
? },
"lint-staged": {
"src/**": [
"prettier --config .prettierrc --write",
"eslint --fix",
"git add"
? ? ]
? }
}
3、對應上述 package.json 里需要的文件進行對應的創建
項目根目錄下創建 .prettierrc
prettier 文檔地址:prettier.io/docs/en/opt…
// .prettierrc
{
"printWidth":200,
"tabWidth":2,
"useTabs":true,
"semi":false,
"singleQuote":true,
"bracketSpacing":true,
"arrowParens":"avoid"
}
4、在工程項目根目錄 .eslintrc.js / .eslintrc.json 添加 rules 規則
項目根目錄下 .eslintrc.js 中添加 rules 規則
// .eslintrc.js
// extends:["@vue/prettier"] 一定要配置 prettier
module.exports= {
root:true,
? env: {
node:true
? },
extends: ["plugin:vue/essential","@vue/prettier","@vue/typescript"],
? rules: {
"no-console": process.env.NODE_ENV ==="production"?"error":"off",
"no-debugger": process.env.NODE_ENV ==="production"?"error":"off",
"no-dupe-keys":"error",
"no-duplicate-case":"error",
"no-empty": ["error", {"allowEmptyCatch":true}],
"no-ex-assign":"error",
"no-extra-boolean-cast":"error",
"no-extra-semi":"error",
"curly":"error"
? },
? parserOptions: {
parser:"@typescript-eslint/parser"
? }
};
1、項目中配置規則要求使用單引號
git commit 之前代碼截圖如下
git commit -m "自動修復",命令執行后如下圖
上圖所示配置的配置已經生效
代碼自動格式化及自動修復,有效提高了項目的質量和協同作戰的效率
后期可獨立搭建工程化項目,進行更深的規則定制