溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“eslint+prettier+husky如何配置”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“eslint+prettier+husky如何配置”吧！
eslint它規范的是代碼偏向語法層面上的風格。本篇文章以一個基本的vue項目，來說明eslint+prettier+husky配置項目代碼規范，為了更好的描述本文，我恢復了vscode的默認設置（即未安裝eslint,prettier等插件，setting中也沒有相關配置）
vue create eslint-test
npm install eslint --save-dev
npx eslint --init
生成.eslintrc.js文件：
module.exports = {
"env": {
"browser": true,
"es2021": true,
"node": true
},
"extends": [
"eslint:recommended",//繼承Eslint中推薦的（打鉤的）規則項http://eslint.cn/docs/rules/
"plugin:vue/essential"// 此項是用來配置vue.js風格
],
"parserOptions": {
"ecmaVersion": 13,
"sourceType": "module"
},
"plugins": [
"vue"
],
"rules": {
}
};這里的規則，寫在后面的會覆蓋前面的，并且rules中的規則最后會覆蓋這里的，所以我們自定義規則就是寫在rules中，才能覆蓋之前的規則，從而生效。
"extends": [ "eslint:recommended",//繼承Eslint中推薦的（打鉤的）規則項http://eslint.cn/docs/rules/ "plugin:vue/essential"// 此項是用來配置vue.js風格https://eslint.vuejs.org/rules ],
quotes - Rules - ESLint中文
Available rules | eslint-plugin-vue (vuejs.org)
這個默認規則是怎么生效的呢？舉個例子，我們點進去鏈接，可以看到這個no-debugger是打上了對勾（也就是"eslint:recommended"）中生效的規則，然后我們再在項目中寫個debugger，然后命令行運行檢查eslint的命令，就會報錯了。
項目根目錄執行：
npx eslint --ext .vue src/ 等價于：./node_modules/.bin/eslint --ext .vue src/ --ext:可以指定在指定目錄/文件 .vue：vue文件 src/：在src目錄下匹配
Eslint附帶了大量的校驗規則，這些規則的值分別有如下規律：
off | 0 :表示關閉規則。
warn | 1 :表示將該規則轉換為警告。
error | 2 :表示將該規則轉換為錯誤。
常見的rules規則，可以看官網：List of available rules - ESLint中文
// "semi": [2, "always"],//語句強制分號結尾 // "quotes": [2, "double"],//引號類型 "" //"no-alert": 0,//禁止使用alert //"no-console": 2,//禁止使用console //"no-const-assign": 2,//禁止修改const聲明的變量 //"no-debugger": 2,//禁止使用debugger //"no-duplicate-case": 2,//switch中的case標簽不能重復 //"no-extra-semi": 2,//禁止多余的冒號 //"no-multi-spaces": 1,//不能用多余的空格
當我們這樣自定義配置結尾必須分號之后，再運行檢查，項目中就會報對應的錯：
上文中，我們是手動輸入命令行來檢查代碼是否符合eslint規范的，這樣每次檢查都要輸入一遍，有的人要是記不住這命令怎么辦？于是可以在package.json的script中寫死這個腳本：
"lint": "eslint --ext .js --ext .jsx --ext .vue src/",
于是，項目根目錄運行npm run lint，實際上就是運行：
npx eslint --ext .js --ext .jsx --ext .vue src/
從而實現代碼的檢查：
難道每次寫完一句代碼，都要npm run lint來檢查下是否符合規范嘛？那樣太麻煩了。于是有eslint插件，這里我用的是vscode，打開插件市場，搜索到eslint，安裝即可：
安裝了之后什么效果呢？就是它會自動檢查你的代碼是否符號規范，并且會在編輯器中標識出來哪里不符合規范，底下終端處還會羅列出問題：
比如說上文咱們寫了好多這種bug，一個一個手動修復，太麻煩了。eslint提供了一個–fix的命令行，可以實現自動修復不符合規范的代碼，但是這種修復不是萬能的，官網中說，有這個（扳手）????的圖標對應的規則才是可以修復的。
可以看到，debugger這個規則應該是不能修復的，而分號這個是可以自動修復的。
具體的命令行，同樣設置到package.json中：
"lint-fix": "eslint --fix --ext .js --ext .jsx --ext .vue src/"
在根目錄執行這個npm run lint-fix:
可以看到分號的錯誤被修復了，而debugger無法自動修復，只能手動修復。
先不考慮debugger這種只能手動修復的，在實際寫代碼中，更多時候遇到的是分號啦，單雙引號啦這些可以被自動修復的錯誤，那么，我們還需要每次去手動敲npm run lint-fix嘛？那同樣效率很低。現在利用vscode的eslint插件我們已經能一寫完代碼，就知道是否符合規范了。然而我們還想實現的是每次寫完代碼，按下ctrl+s保存時，它能夠自動修復。
幸運的是，vscode的setting.json能夠幫助我們實現這一點：
在vscode中按快捷鍵ctrl+shift+p，輸入setting,打開setting.json
增加這段配置即可（如果未生效重啟vscode）：
//配置保存時按照eslint文件的規則來處理一下代碼
"editor.codeActionsOnSave": {
"source.fixAll": true,
"eslint.autoFixOnSave" : true,
},
可以看到，我一按保存，就自動修復了分號的問題。
有些文件，我們不希望它受eslint管轄，可以在根目錄新建.eslintignore文件，把想要自由的文件或目錄丟進去即可：
.eslintrc.js
.prettierrc.js
babel.config.js
vetur.config.js
/node_modules/
反思幾個問題：
我們為什么需要eslint？
因為每個人的代碼習慣不一樣，每個開發人員都需要和他人協作或者項目需要交接給下一代開發者。保持統一的代碼規范，可以極大地提高效率，降低溝通和理解代碼的成本。
既然已經有vscode的eslint插件幫助我們自動檢查和修復代碼了，為什么還需要在pakage.json中配置eslint命令行？
因為vscode是我們自己電腦上的編輯器，我們不能保證另一個人拿到我們的代碼時他也是用vscode的（也許他用記事本？）。就算他用vscode,我們也不能保證他安裝了eslint插件。 ，他就可以使用pakage.json的命令行來檢查和修復代碼。因為項目中肯定需要安裝eslint依賴，也肯定有我們配置的.eslintrc.js規則文件，這樣依舊能保證代碼的統一規范。
上文我們配置了eslint,它規范的是代碼偏向語法層面上的風格。比如說不能使用console啦，箭頭函數參數必須包裹在括號中啦這些。
而項目中有時候，我們寫代碼刪刪改改，或者是個人的代碼習慣，就有可能出現這樣的代碼：
<script>
import HelloWorld from './components/HelloWorld.vue';
export default {
name: 'App',
components: {
HelloWorld
}
};
</script>排版很亂，或者寫html時，太長了換不換行之類的代碼排版問題，就需要prettier來規范。
也就是說，prettier規范的是代碼偏向于排版層面上的風格。
npm install --save-dev --save-exact prettier
npx prettier --write src/
可以看到，我原先故意寫亂的代碼，變得整齊了。
需要在根目錄新建一個文件.prettierrc.js（則需要module.export）,如果是.prettierrc(則只需要json格式)：
//此處的規則供參考，其中多半其實都是默認值，可以根據個人習慣改寫
module.exports = {
printWidth: 80, //單行長度
tabWidth: 2, //縮進長度
useTabs: false, //使用空格代替tab縮進
semi: false, //句末使用分號
singleQuote: false, //使用單引號
arrowParens: "avoid",//單參數箭頭函數參數周圍使用圓括號-eg: (x) => xavoid：省略括號
bracketSpacing: true,//在對象前后添加空格-eg: { foo: bar }
insertPragma: false,//在已被preitter格式化的文件頂部加上標注
jsxBracketSameLine: false,//多屬性html標簽的‘>'折行放置
rangeStart: 0,
requirePragma: false,//無需頂部注釋即可格式化
trailingComma: "none",//多行時盡可能打印尾隨逗號
useTabs: false//使用空格代替tab縮進
};為了測試是否生效，我故意把句末是否使用分號寫成了false(上文中eslint是需要分號的)。執行npx prettier --write src/，可以看到，分號被取消了，但是不滿足eslint規則，報錯了：
沖突的問題稍后再說，這里只是說明我們配置的.prettierrc.js是生效的。
同樣的，我們不可能每寫一行代碼，就運行npx prettier --write src/來美化一次代碼，我們希望保存代碼時，就能夠自動格式化代碼。于是又需要安裝prettier插件。
然后再ctrl+shift+p打開vscode的setting.json文件，添加如下配置：
//prettier可以格式化很多種格式，所以需要在這里對應配置下
"[html]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[css]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[less]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[vue]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescriptreact]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[jsonc]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[json]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
//這個設置在ctrl+s的時候，會啟用默認的格式化，這里是prettier
"editor.formatOnSave": true這時候按保存代碼，會發現在閃動，依舊是報eslint的錯：
這是因為eslint的規則和prettier沖突了，當我們保存的時候。先執行eslint的自動修復，于是分號會加上。然后又執行prettier的修復，分號又去除，這就導致閃動，到頭來還是報eslint的錯。這里主要是體現prettier在保存代碼時能夠自動修復，沖突的問題依舊先放到后面說。
到目前為止，對于prettier,我們還無法查看哪里不符合規則，而只是通過自動修復來規范代碼風格。現在我們想像eslint一樣，代碼一寫，如果不符合，就出現紅色的波浪線提示哪里有問題。
這個要怎么實現呢？可以利用eslint的報錯，把prettier當成eslint的插件注入eslint中，讓eslint來報這個錯（實際上還是vscode的eslint實現的）
安裝依賴：
npm i -D eslint-plugin-prettier
然后再在.eslintrc.js 配置文件中添加這個配置，意思就是使用 eslint 報prettier的錯誤：
// .eslintrc.js
{
"plugins": ["prettier"],
"rules": {
"prettier/prettier": "error"
}
}這樣設置后，我故意把代碼排版變亂：
可以注意到，編輯器已經可以同時報eslint和prettier的錯誤了。
這時保存下代碼，除了沖突的部分，都會被自動修復。
接下來可以著手解決這兩家伙沖突的問題了。
先說一個事情，其實上文中我反復說的沖突。并不是真正意義上的eslint和prettier的沖突。因為上文的沖突，eslint的規則設置在.eslintrc.js的rules中，prettier的設置在prettierrc.js中，這兩者都是我們開發者自己設置的！這分明是前端程序員自己傻逼，給編輯器下絆子！（這么說大家別打我，我還年輕還沒娶媳婦……）
我解釋一下沖突的緣由，就能夠理解我為啥這么說了。
首先，我們是安裝了eslint。
那這個eslint要能校驗代碼，它肯定是有一套默認的代碼規范的。
上文中第一章節第三點說過
"extends": [ "eslint:recommended",//繼承Eslint中推薦的（打鉤的）規則項http://eslint.cn/docs/rules/ "plugin:vue/essential"// 此項是用來配置vue.js風格 ],
這里的eslint:recommended就是這套默認規則，當然有時候我們不用這套規則。會用其他成熟的規則方案例如Airbnb 規范。比如這里我就額外引入了plugin:vue/essential，作為vue文件的規范。
這里需要再強調一點，這個extends數組中的規則，后面的會覆蓋前面的，也就是vue/essential會覆蓋掉recommended中的重復部分。
并且這里的規則是由安裝依賴引入的，存放在node_modules文件夾中，也就是為了保證其他開發人員代碼一致，這里面的文件是不允許改動的。
所以說eslint和prettier的沖突問題，其實說的是這些依賴引入的規則和prettier的沖突！
而不是你自己配置的eslint中的rules和你自己配置的prettier沖突。
為了證明我的說法，我去node_modules/eslint/conf/eslint-recommended.js增加一個eslint規則：（這個文件中設置的規則上文說過是官網中打了勾的部分，quotes不在默認規則里，為了好理解，我手動添加一個）
現在eslint中的配置是這樣，我把自定義的配置關閉掉，prettier中是這樣。即eslint默認配置需要雙引號，prettier設置需要單引號，兩者是沖突的：
這時候我再按ctrl+s保存代碼，就可以看到兩者沖突了。（修改后未生效，需要重啟vscode）:
網上說的解決沖突的依賴安裝一下：
npm i -D eslint-config-prettier
把prettier設置的規則添加到extends數組中：
extends: [ 'eslint:recommended', //繼承Eslint中推薦的（打鉤的）規則項http://eslint.cn/docs/rules/ 'plugin:vue/essential', // 此項是用來配置vue.js風格 'prettier',//把prettier中設置的規則添加進來，讓它覆蓋上面設置的規則。這樣就不會和上面的規則沖突了 ],
這樣一來，就讓在它之前的所有可能會與 prettier 規則存在沖突的 eslint規則失效，并使用 prettier 的規則進行代碼檢查。
接著，在項目中ctrl+s報錯代碼，可以看到報錯消失，變成了prettier設置的單引號了：
這才是真正意義上的解決沖突。
接下來，再來說rules中的沖突怎么辦？它的優先級要高于extends中的規則，而extends中沖突的規則已經被prettier搞失效了，你又在rules中再定義，于是又會和prettier中產生沖突。
也就是說，上文解決沖突只會解決extends中的沖突。不會解決rules中的沖突！
那我們這種沖突應該怎么解決？
第一種方案：把自己想要的規則配置成npm包發布，然后引入到這個extends數組中。
第二種方案：relus中的配置和prettier中的保持一致即可。
有的時候，我們的項目并沒有配置prettier,而我們希望在vscode中可以在保存代碼時美化代碼。就可以在ctrl+shift+p打開setting.json配置prettier規則：
/* prettier的配置 */
"prettier.printWidth": 80, // 超過最大值換行
"prettier.tabWidth": 2, // 縮進字節數
"prettier.useTabs": false, // 句尾添加分號
"prettier.singleQuote": false, // 使用單引號代替雙引號
"prettier.proseWrap": "preserve", // (x) => {} 箭頭函數參數只有一個時是否要有小括號。avoid：省略括號
"prettier.bracketSpacing": true, // 在對象，數組括號與文字之間加空格 "{ foo: bar }"
"prettier.endOfLine": "auto", // 結尾是 \n \r \n\r auto
"prettier.eslintIntegration": false, //不讓prettier使用eslint的代碼格式進行校驗
"prettier.htmlWhitespaceSensitivity": "ignore",
"prettier.ignorePath": ".prettierignore", // 不使用prettier格式化的文件填寫在項目的.prettierignore文件中
"prettier.jsxBracketSameLine": false, // 在jsx中把'>' 是否單獨放一行
"prettier.jsxSingleQuote": false, // 在jsx中使用單引號代替雙引號
"prettier.parser": "babylon", // 格式化的解析器，默認是babylon
"prettier.requireConfig": false, // Require a 'prettierconfig' to format prettier
"prettier.stylelintIntegration": false, //不讓prettier使用stylelint的代碼格式進行校驗
"prettier.trailingComma": "none", // 在對象或數組最后一個元素后面是否加逗號（在ES5中加尾逗號）
"prettier.tslintIntegration": false,
"prettier.arrowParens": "avoid"反思問題：
既然vscode中設置了pettier(上文第八點)，已經能夠格式化代碼了，還要安裝prettier依賴，去配置格式。
原因和eslint中一樣，vscode中配置的，其他人也許不用vscode，也許安裝了vscode,但是沒有在setting.json中設置規范。而項目讀取prettier規范時有一個優先級的，如果在根目錄找到了.prettier文件，則不會去查找setting.json中的規則了。只有找不到.prettier文件時，我們配置在setting.json中的規則才會生效。
為了保證每次提交的 git 代碼是正確的，為此我們可以使用 eslint 配合 git hook， 在進行git commit 的時候驗證eslint規范
如果 eslint 驗證不通過，則不能提交。
我們需要安裝一個 git 的 hook 工具 – husky （我剛開始安裝的是最新版本，發現沒有生效，回退后才生效）
npm install husky@4.3.8 --save-dev
然后在package.json中增加配置：
"husky": {
"hooks": {
"pre-commit": "echo 'husky' && npm run lint"
}
}意思是在進行 git commit 的時候 先去執行 pre-commit 里面的命令 ： 我們在這里輸出 husky 并且執行 npm run lint (我們在上文第一章，第5點加上的驗證eslint的命令)
如果eslint驗證通過了，則會進行commit 操作，否則會報eslint的錯誤提示。
生效的標志是項目的.git/hooks目錄下，會生成一堆文件，原本是只有pre-commit.sample這類文件，等husky安裝完成，會多出pre-commit等文件。
再運行git commit命令，就會檢查代碼了。
如果這是一個新項目以上的就已經滿足要求了，但是如果拿到的項目是一個老項目呢，別人開發了很久，這個時候加入再加入 eslint 規則，全局去檢查，會發現一堆報錯信息。這個就慌了。修改可能帶來其他問題。
為了解決這種問題，我們就需要引入 lint-staged
lint-staged 的作用是只對 git add 緩存區的代碼進行 eslint 代碼規范校驗。這樣就避免了全局校驗的問題。你修改了上面代碼，你就提交了什么代碼，其他代碼不做 eslint 校驗。
npm install --save-dev lint-staged
在 package.json 中添加：
"lint-staged": {
"src/**/*.{css，scss,less}": [
"npm run lint",
"git commit"
],
"src/**/*.{js,vue}": [
"npm run lint",
"git commit"
]
}感謝各位的閱讀，以上就是“eslint+prettier+husky如何配置”的內容了，經過本文的學習后，相信大家對eslint+prettier+husky如何配置這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
