代碼規(guī)范之-理解ESLint、Prettier、EditorConfig
加入我們一起學(xué)習(xí)，天天進(jìn)步
轉(zhuǎn)載自：nowThen
https://juejin.cn/post/6895889063111294990
前言
團(tuán)隊(duì)多人協(xié)同開(kāi)發(fā)項(xiàng)目中困惱團(tuán)隊(duì)管理一個(gè)很大的問(wèn)題是：無(wú)可避免地會(huì)出現(xiàn)每個(gè)開(kāi)發(fā)者編碼習(xí)慣不同、代碼風(fēng)格迥異，為了代碼高可用、可維護(hù)性， 如何從項(xiàng)目管理上盡量統(tǒng)一和規(guī)范代碼呢？
[x] 文檔約定 - 諄諄教導(dǎo)，自求多福？
[x] 經(jīng)常性CodeRevice - 苦口婆心，耳提面命？
顯然這種無(wú)法實(shí)時(shí)反饋、延遲解決的方式會(huì)造成溝通成本高，往往最終結(jié)果還不太理想...
理想的方式是在項(xiàng)目工程化層面 借助可靈活配置的工具，自動(dòng)化 解決。
而于此對(duì)應(yīng)的，
細(xì)心的你，如果仔細(xì)觀察，會(huì)發(fā)現(xiàn)無(wú)論是開(kāi)源項(xiàng)目還是成熟的團(tuán)隊(duì)項(xiàng)目，打開(kāi)項(xiàng)目源碼，你會(huì)發(fā)現(xiàn)根目錄下出現(xiàn)了越來(lái)越多的配置文件，這是前端項(xiàng)目在快速演變、逐漸完善健壯的一種表現(xiàn)。而對(duì)于我們來(lái)說(shuō)，傻傻分不清楚可不行。
今天，我們就來(lái)分析一下跟編碼風(fēng)格、代碼規(guī)范相關(guān)的
、
、
這幾個(gè)常見(jiàn)配置功能。
借助于EditorConfig+Prettier+ESLint?的組合，項(xiàng)目中通過(guò)統(tǒng)一約定配置，可以在團(tuán)隊(duì)成員在代碼開(kāi)發(fā)過(guò)程中就檢查、約束、美化代碼，統(tǒng)一編碼風(fēng)格；且可以省去很多的溝通成本，提前暴露代碼缺陷，減少后期二次修改代碼的風(fēng)險(xiǎn)；
簡(jiǎn)單歸納：
EditorConfig: 跨編輯器和IDE編寫(xiě)代碼，保持一致的簡(jiǎn)單編碼風(fēng)格； Prettier: 專注于代碼格式化的工具，美化代碼； ESLint：作代碼質(zhì)量檢測(cè)、編碼風(fēng)格約束等；
當(dāng)然，他們各有適用范圍，接下來(lái)，我們就來(lái)一探究竟，重點(diǎn)關(guān)注ESLint。
EditorConfig
EditorConfig有助于從事同一項(xiàng)目的多個(gè)開(kāi)發(fā)人員在跨多個(gè)編輯器和IDE使用時(shí)保持一致的編碼風(fēng)格。
EditorConfig項(xiàng)目包含一個(gè)用于定義編碼樣式的文件格式和一個(gè)文本編輯器插件集合，這些文本編輯器插件使編輯器可以讀取文件格式并遵循定義的樣式。
解讀
依賴編輯器IDE的支持
某些編輯器已默認(rèn)集成對(duì)EditorConfig的支持，比如常用的：Webstorm、IntelliJ IDEA等；
而另一些編輯器則需要借助安裝對(duì)應(yīng)的插件來(lái)支持：比如 Visual Studio Code、Atom等；
我們常用的Visual Studio Code安裝的必裝插件：
支持多種文件格式
編輯器讀取到文件格式會(huì)匹配并遵循配置文件定義的規(guī)則；
就近原則
打開(kāi)文件時(shí)，EditorConfig插件會(huì)在打開(kāi)的文件的目錄中以及每個(gè)父目錄中查找名為.editorconfig的文件。如果到達(dá)根文件路徑或找到root = true的EditorConfig文件，將停止對(duì).editorconfig文件的搜索。
離文件最近的配置規(guī)則生效，優(yōu)先級(jí)更高；一般在根目錄設(shè)置一個(gè)配置文件即可。
配置文件? .editorconfig
定義規(guī)則配置，來(lái)避免常見(jiàn)的代碼格式不一致和丑陋的 diffs。例如常見(jiàn)配置項(xiàng)：
#?http://editorconfig.org
root?=?true
#?說(shuō)明
##?設(shè)置文件編碼為 UTF-8；
##?用兩個(gè)空格代替制表符；
##?在保存時(shí)刪除尾部的空白字符；
##?在文件結(jié)尾添加一個(gè)空白行；
[*]
indent_style?=?space
indent_size?=?2
end_of_line?=?lf
charset?=?utf-8
trim_trailing_whitespace?=?true
insert_final_newline?=?true
[*.md]
trim_trailing_whitespace?=?false
[Makefile]
indent_style?=?tab
復(fù)制代碼
更多內(nèi)容可以訪問(wèn)官網(wǎng)查看。
當(dāng)然，我們看到EditorConfig包含的內(nèi)容比較少，主要是配置我們的編輯器，編寫(xiě)代碼時(shí)的簡(jiǎn)單規(guī)則，不足以滿足項(xiàng)目更多需求；
Prettier
Prettier是一個(gè)誕生于2016年就迅速流行起來(lái)的專注于代碼格式化的工具。出道即巔峰啊-.-Prettier只關(guān)注格式化，并不具有l(wèi)int檢查語(yǔ)法等能力。它通過(guò)解析代碼并匹配自己的一套規(guī)則，來(lái)強(qiáng)制執(zhí)行一致的代碼展示格式。
它在美化代碼方面有很大的優(yōu)勢(shì)，配合ESLint可以對(duì)ESLint格式化基礎(chǔ)上做一個(gè)很好的補(bǔ)充。
那么如何使用呢？
單獨(dú)使用，配合編輯器IDE作代碼格式化； 與ESLint等配合使用；在下文ESLint中詳細(xì)談，此處不予贅述；
1. 單獨(dú)使用，配合編輯器IDE作代碼格式化
以VSCode為例，首先安裝Prettier插件。
VSCode內(nèi)置的代碼格式化工具可以指定為由Prettier接管，此時(shí)右下角會(huì)顯示為Prettier。可以自行配置格式化觸發(fā)機(jī)制：換行時(shí)格式化、保存文件時(shí)格式化、還是自行快捷鍵觸發(fā)；
本人的使用習(xí)慣是用快捷鍵手動(dòng)觸發(fā)格式化。
當(dāng)在編輯器里格式化未生效時(shí)，可以在.settings.json里檢查對(duì)應(yīng)文件格式指定的格式化程序并調(diào)整就可以：
這樣在VSCode編輯器里，觸發(fā)文件格式化時(shí)就能根據(jù)配置自動(dòng)美化格式代碼；
配置項(xiàng)：
可以在VSCode?首選項(xiàng)-設(shè)置-擴(kuò)展或.settings.json中更改通用配置；
當(dāng)然還可以在具體項(xiàng)目根目錄設(shè)置.prettierrc單獨(dú)配置；
比如以下一些配置：
{
??//?設(shè)置強(qiáng)制單引號(hào)
??"singleQuote":?true,
??//?為多行數(shù)組的非末尾行添加逗號(hào)?es5的對(duì)象，數(shù)組等
??"trailingComma":?"es5",
??//?每行最大寬度?100
??"printWidth":?100,
??//?設(shè)置語(yǔ)句末尾不加分號(hào)
??"semi":?false,
??//?jsx中使用單引號(hào)
??"jsxSingleQuote":?true,
}
復(fù)制代碼
最后格式化的生效策略同樣是就近原則，一步步匹配目標(biāo)文件最近父目錄的配置文件，越近優(yōu)先級(jí)越高。
ESLint
ESLint 是一個(gè)在 JavaScript 代碼中通過(guò)規(guī)則模式匹配作代碼識(shí)別和報(bào)告的插件化的檢測(cè)工具，它的目的是保證代碼規(guī)范的一致性和及時(shí)發(fā)現(xiàn)代碼問(wèn)題、提前避免錯(cuò)誤發(fā)生。
ESLint 的關(guān)注點(diǎn)是代碼質(zhì)量，檢查代碼風(fēng)格并且會(huì)提示不符合風(fēng)格規(guī)范的代碼。除此之外 ESLint 也具有一部分代碼格式化的功能。
我們跟著ESLint官網(wǎng)的說(shuō)明，來(lái)理解ESLint。
Lint發(fā)展歷程
ESLint最初是由Nicholas C. Zakas ( JavaScript 高級(jí)程序設(shè)計(jì) 作者)于2013年6月創(chuàng)建的開(kāi)源項(xiàng)目。它的目標(biāo)是提供一個(gè)插件化的javascript代碼檢測(cè)工具。
JavaScript發(fā)展歷程中出現(xiàn)的Lint工具：JSLint->JSHint->ESLint/TSLint；
JSLint是最早出現(xiàn)的 Lint 工具，不支持靈活拓展及配置，必須接受它所有規(guī)則； JSHint 在 JSLint 的基礎(chǔ)上提供了一定的配置項(xiàng)，給了開(kāi)發(fā)者較大的自由，但無(wú)法添加自定義規(guī)則； Zakas創(chuàng)建ESLint的初衷就是覺(jué)得當(dāng)時(shí)的JSHint存在局限性，無(wú)法添加自定義規(guī)則。 ES6的出現(xiàn)后則讓ESLint迅速大火。
因?yàn)镋S6新增了很多語(yǔ)法，JSHint 短期內(nèi)無(wú)法提供支持，而 ESLint 只需要有合適的解析器以及拓展校驗(yàn)規(guī)則 就能夠進(jìn)行 Lint 檢查。此時(shí)babel就為兼容ESLint開(kāi)發(fā)了 babel-eslint解析器，提供支持的同時(shí)也讓ESLint成為最快支持 ES6 語(yǔ)法的 Lint 工具。
關(guān)于TSLint(已停止維護(hù))
使用過(guò)TypeScript的童鞋對(duì)于TSLint應(yīng)該不會(huì)陌生，它是由TypeScript團(tuán)隊(duì)推出并維護(hù)的。
但自2019 年 1 月起，根據(jù) TSLint 的官方聲明，TSLint 正在慢慢被廢棄，并會(huì)逐步遷移到 ESLint作為代碼檢查的工具。
至于停止維護(hù)的原因：一是ESLint社區(qū)更活躍、越來(lái)越完善，且社區(qū)對(duì)ESLint的擁護(hù)聲浪越來(lái)越高，相反TSLint則完善度不夠；二是在持續(xù)迭代、支持新特性的過(guò)程中發(fā)現(xiàn)TSLint 的規(guī)則運(yùn)作方式存在架構(gòu)性的性能問(wèn)題，相反的 ESLint 則具有更高效能的架構(gòu)。
不過(guò)不得不感慨一句：即使官方已聲明停止更新很長(zhǎng)時(shí)間了，你會(huì)發(fā)現(xiàn)還是有很多TypeScript項(xiàng)目采用TSLint作為代碼檢查的工具，未做遷移。
如果你的項(xiàng)目還在使用TSLint，為了項(xiàng)目的長(zhǎng)期維護(hù)性和獲得更好的ts代碼檢查使用體驗(yàn)，盡快遷移至ESLint；
下圖為JSHint、TSLint、ESLint、Prettier的Npm包下載量對(duì)比圖：
那么ESLint出現(xiàn)的意義是什么？
ESLint官網(wǎng)的說(shuō)明：代碼檢查是一種靜態(tài)的分析，常用于尋找有問(wèn)題的模式或者代碼，并且不依賴于具體的編碼風(fēng)格。對(duì)大多數(shù)編程語(yǔ)言來(lái)說(shuō)都會(huì)有代碼檢查，一般來(lái)說(shuō)編譯程序會(huì)內(nèi)置檢查工具。
JavaScript 是一個(gè)動(dòng)態(tài)的弱類型語(yǔ)言，在開(kāi)發(fā)中比較容易出錯(cuò)。因?yàn)闆](méi)有編譯程序，為了尋找 JavaScript 代碼錯(cuò)誤通常需要在執(zhí)行過(guò)程中不斷調(diào)試。像 ESLint 這樣的可以讓程序員在編碼的過(guò)程中發(fā)現(xiàn)問(wèn)題而不是在執(zhí)行的過(guò)程中。
與Java等編程語(yǔ)言不同，JavaScript作為弱類型的動(dòng)態(tài)語(yǔ)言，因?yàn)槿鄙倬幾g階段，有些本可以在編譯過(guò)程中發(fā)現(xiàn)的錯(cuò)誤，只能等到運(yùn)行時(shí)才發(fā)現(xiàn)，這給我們調(diào)試和提前發(fā)現(xiàn)隱藏問(wèn)題增加了一些難度，而 Lint 工具相當(dāng)于為js增加了編譯過(guò)程，在代碼部署運(yùn)行前進(jìn)行靜態(tài)分析，找到出錯(cuò)的地方和不規(guī)范的代碼。
那么 TypeScript 已經(jīng)能夠在編譯階段檢查出很多問(wèn)題了，為什么還需要Lint工具代碼檢查呢？
因?yàn)?TypeScript 關(guān)注的重心是類型的檢查，而不是代碼風(fēng)格。
總結(jié)一下ESLint的作用及優(yōu)勢(shì)：
檢查語(yǔ)法錯(cuò)誤，避免低級(jí)bug；
比如：api語(yǔ)法錯(cuò)誤、使用了未定義的變量、修改const變量
統(tǒng)一團(tuán)隊(duì)代碼風(fēng)格
比如：使用tab還是空格，使用單引號(hào)還是雙引號(hào)等
確保代碼遵循最佳實(shí)踐
比如：可以借助
eslint-config-standard配置包擴(kuò)展社區(qū)中流行的最佳實(shí)踐的風(fēng)格指南。
這樣就能極大提高項(xiàng)目中多人協(xié)作開(kāi)發(fā)時(shí)的效率、代碼的可讀性以及可維護(hù)性。
ESLint特點(diǎn)
一、ESLint 的所有規(guī)則都被設(shè)計(jì)成可插拔的
每條校驗(yàn)規(guī)則都是獨(dú)立的，可以單獨(dú)開(kāi)啟或關(guān)閉（沒(méi)有什么可以被認(rèn)為“太重要所以不能關(guān)閉”），還可以將結(jié)果設(shè)置成警告或者錯(cuò)誤。
在規(guī)則編寫(xiě)時(shí)，每個(gè)規(guī)則都是單獨(dú)的文件和對(duì)應(yīng)的格式化方法。
二、ESLint是完全可配置的
ESlint 被設(shè)計(jì)為完全可配置的，除了規(guī)則可插拔，還可以編寫(xiě)自定義規(guī)則、引入社區(qū)規(guī)則配置集、插件等，讓ESLint更契合每個(gè)項(xiàng)目的具體需求情況；
通過(guò)?eslint-plugin-react配置包擴(kuò)展支持React語(yǔ)法；
通過(guò)@typescript-eslint/parser解析器支持typeScript語(yǔ)法及校驗(yàn)等；
三、ESLint 使用 Node.js 編寫(xiě)
在前端項(xiàng)目中便于安裝且有一個(gè)快速的運(yùn)行環(huán)境；
減輕了開(kāi)發(fā)者編寫(xiě)自定義規(guī)則的門檻；
四、ESLint解析時(shí)將源碼先轉(zhuǎn)換成AST
ESLint 使用 Esprima 將源代碼解析成 AST來(lái)分析代碼中的模式，再通過(guò)匹配規(guī)則定義識(shí)別和報(bào)告搜集的代碼信息。
雖然多轉(zhuǎn)換一層效率略微降低，好處是可以支持使用任意規(guī)則來(lái)檢測(cè) AST 是否符合預(yù)期，這使得 ESLint 高可擴(kuò)展性。
支持的配置文件格式
ESLint 支持幾種格式的配置文件：
JavaScript?- 使用? .eslintrc.js?然后輸出一個(gè)配置對(duì)象。YAML?- 使用? .eslintrc.yaml?或?.eslintrc.yml?去定義配置的結(jié)構(gòu)。JSON?- 使用? .eslintrc.json?去定義配置的結(jié)構(gòu)，ESLint 的 JSON 文件允許 JavaScript 風(fēng)格的注釋。(棄用)?- 使用? .eslintrc，可以使 JSON 也可以是 YAML。package.json?- 在? package.json?里創(chuàng)建一個(gè)?eslintConfig屬性，在那里定義你的配置。
如果同一個(gè)目錄下有多個(gè)配置文件，ESLint 只會(huì)使用一個(gè)。優(yōu)先級(jí)順序如下：
.eslintrc.js.eslintrc.yaml.eslintrc.yml.eslintrc.json.eslintrcpackage.json
遇到項(xiàng)目?jī)?nèi)有多個(gè)層疊配置時(shí)，依然采用就近原則作為高優(yōu)先級(jí)；
配置文件說(shuō)明
Rules-啟用的規(guī)則及其各自的錯(cuò)誤級(jí)別
ESLint 附帶有大量的規(guī)則。你可以使用注釋或配置文件修改你項(xiàng)目中要使用的規(guī)則。要改變一個(gè)規(guī)則設(shè)置，你必須將規(guī)則 ID 設(shè)置為下列值之一：
"off"?或?0?- 關(guān)閉規(guī)則"warn"?或?1?- 開(kāi)啟規(guī)則，使用警告級(jí)別的錯(cuò)誤：warn?(不會(huì)導(dǎo)致程序退出)"error"?或?2?- 開(kāi)啟規(guī)則，使用錯(cuò)誤級(jí)別的錯(cuò)誤：error?(當(dāng)被觸發(fā)的時(shí)候，程序會(huì)退出)
Globals-配置額外的全局變量
啟用ESLint規(guī)則后，當(dāng)訪問(wèn)當(dāng)前源文件內(nèi)未定義的變量時(shí)，no-undef 規(guī)則將發(fā)出警告。
而有時(shí)候，我們是需要在其他文件訪問(wèn)一些全局變量的，且保證能正常取到值。這時(shí)可以在 ESLint 中定義這些全局變量，這樣 ESLint 就不會(huì)發(fā)出警告了。
用注釋指定全局變量，格式如下：
/*?global?var1,?var2?*/
復(fù)制代碼
這定義了兩個(gè)全局變量，var1?和?var2。如果你想選擇性地指定這些全局變量可以被寫(xiě)入(而不是只被讀取)，那么你可以用一個(gè)?"writable"?的標(biāo)志來(lái)設(shè)置它們:
/*?global?var1:writable,?var2:writable?*/
復(fù)制代碼
配置文件中通過(guò) globals?配置屬性設(shè)置，對(duì)于每個(gè)全局變量鍵，將對(duì)應(yīng)的值設(shè)置為?"writable"?以允許重寫(xiě)變量，或?"readonly"?不允許重寫(xiě)變量。例如：
//?.eslintrc.js
"globals":?{
??"var1":?"writable",
??"var2":?"readonly"
}
復(fù)制代碼
Environments - 指定腳本的運(yùn)行環(huán)境
每種環(huán)境都有一組特定的預(yù)定義全局變量。如brower、node環(huán)境變量、es6環(huán)境變量等。
'env':?{
??'browser':?true,
??'commonjs':?true,
??'es6':?true
},
復(fù)制代碼
Plugins - 第三方插件
ESLint 支持使用第三方插件，先在項(xiàng)目中下載安裝要引入的插件，配置文件中使用?plugins?關(guān)鍵字來(lái)存放插件名字的列表。插件名稱可以省略?eslint-plugin-?前綴。
?plugins:?['react',?'babel'],?//?eslint-plugin-react?eslint-plugin-babel
復(fù)制代碼
Extends - 繼承
一個(gè)配置文件可以被基礎(chǔ)配置中的已啟用的規(guī)則繼承。
?extends:?["eslint:recommended","plugin:prettier/recommended"],
復(fù)制代碼
配置代碼注釋方式
有時(shí)候，我們需要在代碼中忽略ESLint的某些規(guī)則檢查，此時(shí)我們可以通過(guò)加入代碼注釋的方式解決：可以指定整個(gè)文件、某一行、某一區(qū)塊開(kāi)啟/關(guān)閉 某些或全部規(guī)則檢查；
/*?eslint-disable?*/????--禁用全部規(guī)則??放在文件頂部則整個(gè)文件范圍都不檢查
/*?eslint-disable?no-alert,?no-console?*/??--禁用某些規(guī)則
//?eslint-disable-line?????--當(dāng)前行上禁用規(guī)則
//?eslint-disable-next-line?--下一行上禁用規(guī)則
復(fù)制代碼
具體參考：eslint.bootcss.com/docs/user-g…；
使用ESLint
安裝 ESLint
ESLint 可以安裝在當(dāng)前項(xiàng)目中或全局環(huán)境下，但因項(xiàng)目間存在的差異性，我們一般會(huì)將它安裝在當(dāng)前項(xiàng)目中。安裝：
yarn?add?--save-dev?eslint
復(fù)制代碼
安裝插件和解析器
假如項(xiàng)目中使用了TypeScript和React，則安裝：
//?我們需要安裝?@typescript-eslint/parser，替代掉默認(rèn)的Espree解析器。
yarn?add?--save-dev?typescript?@typescript-eslint/parser
//?安裝eslint-plugin-react配置包擴(kuò)展支持React語(yǔ)法；安裝@typescript-eslint/eslint-plugin提供額外的ts 語(yǔ)法的規(guī)則
yarn?add?--save-dev?eslint-plugin-react?@typescript-eslint/eslint-plugin
復(fù)制代碼
其他的插件和解析器請(qǐng)根據(jù)實(shí)際項(xiàng)目需要安裝。
創(chuàng)建配置文件
我們?cè)陧?xiàng)目的根目錄下創(chuàng)建一個(gè)?.eslintrc.js，內(nèi)容如下：
module.exports?=?{
????parser:?'@typescript-eslint/parser',
????plugins:?['react','@typescript-eslint'],
????rules:?{
????????//?禁止使用?var
????????'no-var':?"error",
????????//?優(yōu)先使用?interface?而不是?type
????????'@typescript-eslint/consistent-type-definitions':?[
????????????"error",
????????????"interface"
????????]
????}
}
復(fù)制代碼
站在巨人的肩膀上使用
前端社區(qū)中有很多比較好的規(guī)則集，我們要做的是站在巨人的肩膀上，基于已有規(guī)則集，構(gòu)建適合自己及團(tuán)隊(duì)的規(guī)則配置。
通過(guò)研究他人優(yōu)秀的規(guī)則集，慢慢地構(gòu)建自用或公司的規(guī)則配置；
本篇文章介紹的ESLint只是涉及的一些重要的概念及基本使用。ESLint規(guī)則及配置包含了很多的內(nèi)容，想要用的好，值得花精力自行好好研究。
Q&A
1. 如何方便地開(kāi)始使用ESLint，而且盡量不改動(dòng)以前的代碼？
如果你正在使用GIt做項(xiàng)目代碼管理，那么則可以借助husky + lint-staged + Prettier 在Git提交時(shí)，自動(dòng)強(qiáng)制校驗(yàn)并格式化且修復(fù)代碼，而且只處理自己本次改動(dòng)提交的文件。
采用這種pre-commit階段增量校驗(yàn)的模式，盡量避免對(duì)老舊代碼的影響；這種方式可以穩(wěn)健地逐步完善老項(xiàng)目；
2. 如何解決Prettier與ESLint的配置沖突問(wèn)題？
在代碼格式化時(shí)采用Perttier規(guī)則，而我們代碼校驗(yàn)使用的是ESLint，如果同一個(gè)規(guī)則配置不一致，往往就會(huì)出現(xiàn)沖突問(wèn)題；
比如：字符串單、雙引號(hào)的配置，eslint fix后把字符串變成單引號(hào)，再次編輯文件后，保存（Prettier）自動(dòng)格式化后卻又變成雙引號(hào)，導(dǎo)致代碼校驗(yàn)異常。
解決方式一：要么修改 eslintrc，要么修改 prettierrc 配置，讓它們配置保持一致；
解決方式二：禁用 ESLint中和Prettier配置有沖突的規(guī)則；再使用 Prettier 來(lái)替代 ESLint 的格式化功能；
安裝eslint-config-prettier插件配置集，把其配置到eslintrc規(guī)則的尾部。執(zhí)行ESLint命令，會(huì)禁用那些和Prettier配置有沖突的規(guī)則。
安裝eslint-plugin-prettier插件，先使用Prettier對(duì)代碼進(jìn)行格式化，再并對(duì)不一致的地方進(jìn)行標(biāo)記；
這兩個(gè)包配合使用，可以達(dá)到運(yùn)行?eslint \--fix?時(shí)，采用Prettier的配置規(guī)則 來(lái)格式化文件。
具體配置及使用方式，請(qǐng)自行查閱探索；
總結(jié)
ESLint、Prettier、EditorConfig的引入，需要犧牲一些開(kāi)發(fā)人員的編碼自由，來(lái)保證團(tuán)隊(duì)成員代碼風(fēng)格的一致性，進(jìn)而提高代碼的可讀性、可維護(hù)性。使項(xiàng)目更好管理，成員之間合作更順暢。
就算不從團(tuán)隊(duì)開(kāi)發(fā)考慮，個(gè)人從中也能逐漸建立良好的開(kāi)發(fā)規(guī)范，對(duì)于自己的成才也是長(zhǎng)久的。
當(dāng)然，我們也該清楚地認(rèn)識(shí)到工具的局限性：
一、清楚定位：
ESLint等解決的是團(tuán)隊(duì)開(kāi)發(fā)規(guī)范的問(wèn)題，并不能解決其他諸如編碼能力、代碼合理性等問(wèn)題， 還屬于工程化中比較弱的一環(huán)。
有時(shí)會(huì)遇到團(tuán)隊(duì)制定特別嚴(yán)格的規(guī)則校驗(yàn)，且在每次代碼提交時(shí)，收集檢查結(jié)果作為代碼質(zhì)量評(píng)估的重要指標(biāo)。個(gè)人認(rèn)為這種方式固然可以量化一部分代碼質(zhì)量考核問(wèn)題 ，但形式主義過(guò)重。不過(guò)也是廖勝于無(wú)的做法。
太過(guò)嚴(yán)格的規(guī)則，限制了代碼的靈活性。每一個(gè)規(guī)則都應(yīng)該是可被討論，具體開(kāi)啟與否應(yīng)該視團(tuán)隊(duì)而定； 語(yǔ)言或框架某個(gè)寫(xiě)法如果是被嚴(yán)禁使用的，那它就應(yīng)該在源頭被消滅；之所以存在肯定有一定的意義的； ESLint不是神藥，最佳代碼實(shí)踐往往在于多多探索，持續(xù)更新；
二、技術(shù)革新快速，之前認(rèn)為的準(zhǔn)則不一定就適用于當(dāng)下，要保持持續(xù)調(diào)整的心態(tài)和跟進(jìn)優(yōu)化的行動(dòng)力；
三、不要作嚴(yán)格代碼規(guī)范的強(qiáng)迫癥患者， 它并不是目的，只是一個(gè)讓我們更方便管理項(xiàng)目，從復(fù)雜團(tuán)隊(duì)項(xiàng)目解脫出來(lái)的一個(gè)方式。
更傾向的做法是：不要完全依賴工具的規(guī)則校驗(yàn)，要讓它們幫忙我們養(yǎng)成良好的編碼習(xí)慣，培養(yǎng)代碼質(zhì)量意識(shí)，指引我們寫(xiě)出更優(yōu)的代碼，而不是依賴它
??愛(ài)心三連擊 1.看到這里了就點(diǎn)個(gè)在看支持下吧，你的「點(diǎn)贊，在看」是我創(chuàng)作的動(dòng)力。
2.關(guān)注公眾號(hào)
程序員成長(zhǎng)指北，回復(fù)「1」加入Node進(jìn)階交流群！「在這里有好多 Node 開(kāi)發(fā)者，會(huì)討論 Node 知識(shí)，互相學(xué)習(xí)」！3.也可添加微信【ikoala520】，一起成長(zhǎng)。
“在看轉(zhuǎn)發(fā)”是最大的支持