代碼規(guī)范之-理解ESLint、Prettier、EditorConfig

轉(zhuǎn)載自：nowThen

https://juejin.cn/post/6895889063111294990

前言

團隊多人協(xié)同開發(fā)項目中困惱團隊管理一個很大的問題是：無可避免地會出現(xiàn)每個開發(fā)者編碼習(xí)慣不同、代碼風(fēng)格迥異，為了代碼高可用、可維護性， 如何從項目管理上盡量統(tǒng)一和規(guī)范代碼呢？

• [x] 文檔約定 - 諄諄教導(dǎo)，自求多福？

• [x] 經(jīng)常性CodeRevice - 苦口婆心，耳提面命？

顯然這種無法實時反饋、延遲解決的方式會造成溝通成本高，往往最終結(jié)果還不太理想...
理想的方式是在項目工程化層面 借助可靈活配置的工具，自動化 解決。

而于此對應(yīng)的，
細心的你，如果仔細觀察，會發(fā)現(xiàn)無論是開源項目還是成熟的團隊項目，打開項目源碼，你會發(fā)現(xiàn)根目錄下出現(xiàn)了越來越多的配置文件，這是前端項目在快速演變、逐漸完善健壯的一種表現(xiàn)。而對于我們來說，傻傻分不清楚可不行。

今天，我們就來分析一下跟編碼風(fēng)格、代碼規(guī)范相關(guān)的、
、
這幾個常見配置功能。

借助于EditorConfig+Prettier+ESLint?的組合，項目中通過統(tǒng)一約定配置，可以在團隊成員在代碼開發(fā)過程中就檢查、約束、美化代碼，統(tǒng)一編碼風(fēng)格；且可以省去很多的溝通成本，提前暴露代碼缺陷，減少后期二次修改代碼的風(fēng)險；

簡單歸納：

• EditorConfig: 跨編輯器和IDE編寫代碼，保持一致的簡單編碼風(fēng)格；
• Prettier: 專注于代碼格式化的工具，美化代碼；
• ESLint：作代碼質(zhì)量檢測、編碼風(fēng)格約束等；

當(dāng)然，他們各有適用范圍，接下來，我們就來一探究竟，重點關(guān)注ESLint。

EditorConfig

EditorConfig有助于從事同一項目的多個開發(fā)人員在跨多個編輯器和IDE使用時保持一致的編碼風(fēng)格。

EditorConfig項目包含一個用于定義編碼樣式的文件格式和一個文本編輯器插件集合，這些文本編輯器插件使編輯器可以讀取文件格式并遵循定義的樣式。

解讀

1. 依賴編輯器IDE的支持

某些編輯器已默認(rèn)集成對EditorConfig的支持，比如常用的：Webstorm、IntelliJ IDEA等；
而另一些編輯器則需要借助安裝對應(yīng)的插件來支持：比如 Visual Studio Code、Atom等；

我們常用的Visual Studio Code安裝的必裝插件：

2. 支持多種文件格式

編輯器讀取到文件格式會匹配并遵循配置文件定義的規(guī)則；

3. 就近原則

打開文件時，EditorConfig插件會在打開的文件的目錄中以及每個父目錄中查找名為.editorconfig的文件。如果到達根文件路徑或找到root = true的EditorConfig文件，將停止對.editorconfig文件的搜索。
離文件最近的配置規(guī)則生效，優(yōu)先級更高；一般在根目錄設(shè)置一個配置文件即可。

4. 配置文件?.editorconfig

定義規(guī)則配置，來避免常見的代碼格式不一致和丑陋的 diffs。例如常見配置項：

#?http://editorconfig.org
root?=?true

#?說明
##?設(shè)置文件編碼為 UTF-8；
##?用兩個空格代替制表符；
##?在保存時刪除尾部的空白字符；
##?在文件結(jié)尾添加一個空白行；
[*]
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ǎng)查看。

當(dāng)然，我們看到EditorConfig包含的內(nèi)容比較少，主要是配置我們的編輯器，編寫代碼時的簡單規(guī)則，不足以滿足項目更多需求；

Prettier

Prettier是一個誕生于2016年就迅速流行起來的專注于代碼格式化的工具。出道即巔峰啊-.-
Prettier只關(guān)注格式化，并不具有l(wèi)int檢查語法等能力。它通過解析代碼并匹配自己的一套規(guī)則，來強制執(zhí)行一致的代碼展示格式。
它在美化代碼方面有很大的優(yōu)勢，配合ESLint可以對ESLint格式化基礎(chǔ)上做一個很好的補充。

那么如何使用呢？

1. 單獨使用，配合編輯器IDE作代碼格式化；
2. 與ESLint等配合使用；在下文ESLint中詳細談，此處不予贅述；

1. 單獨使用，配合編輯器IDE作代碼格式化

以VSCode為例，首先安裝Prettier插件。VSCode內(nèi)置的代碼格式化工具可以指定為由Prettier接管，此時右下角會顯示為Prettier。可以自行配置格式化觸發(fā)機制：換行時格式化、保存文件時格式化、還是自行快捷鍵觸發(fā)；

本人的使用習(xí)慣是用快捷鍵手動觸發(fā)格式化。

當(dāng)在編輯器里格式化未生效時，可以在.settings.json里檢查對應(yīng)文件格式指定的格式化程序并調(diào)整就可以：這樣在VSCode編輯器里，觸發(fā)文件格式化時就能根據(jù)配置自動美化格式代碼；

配置項：

可以在VSCode?首選項-設(shè)置-擴展或.settings.json中更改通用配置；
當(dāng)然還可以在具體項目根目錄設(shè)置.prettierrc單獨配置；

比如以下一些配置：

{
??//?設(shè)置強制單引號
??"singleQuote":?true,
??//?為多行數(shù)組的非末尾行添加逗號?es5的對象，數(shù)組等
??"trailingComma":?"es5",
??//?每行最大寬度?100
??"printWidth":?100,
??//?設(shè)置語句末尾不加分號
??"semi":?false,
??//?jsx中使用單引號
??"jsxSingleQuote":?true,
}
復(fù)制代碼

最后格式化的生效策略同樣是就近原則，一步步匹配目標(biāo)文件最近父目錄的配置文件，越近優(yōu)先級越高。

ESLint

ESLint 是一個在 JavaScript 代碼中通過規(guī)則模式匹配作代碼識別和報告的插件化的檢測工具，它的目的是保證代碼規(guī)范的一致性和及時發(fā)現(xiàn)代碼問題、提前避免錯誤發(fā)生。
ESLint 的關(guān)注點是代碼質(zhì)量，檢查代碼風(fēng)格并且會提示不符合風(fēng)格規(guī)范的代碼。除此之外 ESLint 也具有一部分代碼格式化的功能。

我們跟著ESLint官網(wǎng)的說明，來理解ESLint。

Lint發(fā)展歷程

ESLint最初是由Nicholas C. Zakas ( JavaScript 高級程序設(shè)計 作者)于2013年6月創(chuàng)建的開源項目。它的目標(biāo)是提供一個插件化的javascript代碼檢測工具。

JavaScript發(fā)展歷程中出現(xiàn)的Lint工具：JSLint->JSHint->ESLint/TSLint；

• JSLint是最早出現(xiàn)的 Lint 工具，不支持靈活拓展及配置，必須接受它所有規(guī)則；
• JSHint 在 JSLint 的基礎(chǔ)上提供了一定的配置項，給了開發(fā)者較大的自由，但無法添加自定義規(guī)則；
• Zakas創(chuàng)建ESLint的初衷就是覺得當(dāng)時的JSHint存在局限性，無法添加自定義規(guī)則。
• ES6的出現(xiàn)后則讓ESLint迅速大火。
  因為ES6新增了很多語法，JSHint 短期內(nèi)無法提供支持，而 ESLint 只需要有合適的解析器以及拓展校驗規(guī)則 就能夠進行 Lint 檢查。此時babel就為兼容ESLint開發(fā)了 babel-eslint解析器，提供支持的同時也讓ESLint成為最快支持 ES6 語法的 Lint 工具。

關(guān)于TSLint(已停止維護)

使用過TypeScript的童鞋對于TSLint應(yīng)該不會陌生，它是由TypeScript團隊推出并維護的。

但自2019 年 1 月起，根據(jù) TSLint 的官方聲明，TSLint 正在慢慢被廢棄，并會逐步遷移到 ESLint作為代碼檢查的工具。
至于停止維護的原因：一是ESLint社區(qū)更活躍、越來越完善，且社區(qū)對ESLint的擁護聲浪越來越高，相反TSLint則完善度不夠；二是在持續(xù)迭代、支持新特性的過程中發(fā)現(xiàn)TSLint 的規(guī)則運作方式存在架構(gòu)性的性能問題，相反的 ESLint 則具有更高效能的架構(gòu)。

不過不得不感慨一句：即使官方已聲明停止更新很長時間了，你會發(fā)現(xiàn)還是有很多TypeScript項目采用TSLint作為代碼檢查的工具，未做遷移。
如果你的項目還在使用TSLint，為了項目的長期維護性和獲得更好的ts代碼檢查使用體驗，盡快遷移至ESLint；

下圖為JSHint、TSLint、ESLint、Prettier的Npm包下載量對比圖：

那么ESLint出現(xiàn)的意義是什么？

ESLint官網(wǎng)的說明：代碼檢查是一種靜態(tài)的分析，常用于尋找有問題的模式或者代碼，并且不依賴于具體的編碼風(fēng)格。對大多數(shù)編程語言來說都會有代碼檢查，一般來說編譯程序會內(nèi)置檢查工具。

JavaScript 是一個動態(tài)的弱類型語言，在開發(fā)中比較容易出錯。因為沒有編譯程序，為了尋找 JavaScript 代碼錯誤通常需要在執(zhí)行過程中不斷調(diào)試。像 ESLint 這樣的可以讓程序員在編碼的過程中發(fā)現(xiàn)問題而不是在執(zhí)行的過程中。

與Java等編程語言不同，JavaScript作為弱類型的動態(tài)語言，因為缺少編譯階段，有些本可以在編譯過程中發(fā)現(xiàn)的錯誤，只能等到運行時才發(fā)現(xiàn)，這給我們調(diào)試和提前發(fā)現(xiàn)隱藏問題增加了一些難度，而 Lint 工具相當(dāng)于為js增加了編譯過程，在代碼部署運行前進行靜態(tài)分析，找到出錯的地方和不規(guī)范的代碼。

那么 TypeScript 已經(jīng)能夠在編譯階段檢查出很多問題了，為什么還需要Lint工具代碼檢查呢？
因為 TypeScript 關(guān)注的重心是類型的檢查，而不是代碼風(fēng)格。

總結(jié)一下ESLint的作用及優(yōu)勢：

• 檢查語法錯誤，避免低級bug；

比如：api語法錯誤、使用了未定義的變量、修改const變量

• 統(tǒng)一團隊代碼風(fēng)格

比如：使用tab還是空格，使用單引號還是雙引號等

• 確保代碼遵循最佳實踐

比如：可以借助eslint-config-standard配置包擴展社區(qū)中流行的最佳實踐的風(fēng)格指南。

這樣就能極大提高項目中多人協(xié)作開發(fā)時的效率、代碼的可讀性以及可維護性。

ESLint特點

一、ESLint 的所有規(guī)則都被設(shè)計成可插拔的

每條校驗規(guī)則都是獨立的，可以單獨開啟或關(guān)閉（沒有什么可以被認(rèn)為“太重要所以不能關(guān)閉”），還可以將結(jié)果設(shè)置成警告或者錯誤。
在規(guī)則編寫時，每個規(guī)則都是單獨的文件和對應(yīng)的格式化方法。

二、ESLint是完全可配置的

ESlint 被設(shè)計為完全可配置的，除了規(guī)則可插拔，還可以編寫自定義規(guī)則、引入社區(qū)規(guī)則配置集、插件等，讓ESLint更契合每個項目的具體需求情況；
通過?eslint-plugin-react配置包擴展支持React語法；
通過@typescript-eslint/parser解析器支持typeScript語法及校驗等；

三、ESLint 使用 Node.js 編寫

在前端項目中便于安裝且有一個快速的運行環(huán)境；
減輕了開發(fā)者編寫自定義規(guī)則的門檻；

四、ESLint解析時將源碼先轉(zhuǎn)換成AST

ESLint 使用 Esprima 將源代碼解析成 AST來分析代碼中的模式，再通過匹配規(guī)則定義識別和報告搜集的代碼信息。
雖然多轉(zhuǎn)換一層效率略微降低，好處是可以支持使用任意規(guī)則來檢測 AST 是否符合預(yù)期，這使得 ESLint 高可擴展性。

支持的配置文件格式

ESLint 支持幾種格式的配置文件：

• JavaScript?- 使用?.eslintrc.js?然后輸出一個配置對象。
• 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)建一個?eslintConfig屬性，在那里定義你的配置。

如果同一個目錄下有多個配置文件，ESLint 只會使用一個。優(yōu)先級順序如下：

1. .eslintrc.js
2. .eslintrc.yaml
3. .eslintrc.yml
4. .eslintrc.json
5. .eslintrc
6. package.json

遇到項目內(nèi)有多個層疊配置時，依然采用就近原則作為高優(yōu)先級；

配置文件說明

Rules-啟用的規(guī)則及其各自的錯誤級別

ESLint 附帶有大量的規(guī)則。你可以使用注釋或配置文件修改你項目中要使用的規(guī)則。要改變一個規(guī)則設(shè)置，你必須將規(guī)則 ID 設(shè)置為下列值之一：

• "off"?或?0?- 關(guān)閉規(guī)則
• "warn"?或?1?- 開啟規(guī)則，使用警告級別的錯誤：warn?(不會導(dǎo)致程序退出)
• "error"?或?2?- 開啟規(guī)則，使用錯誤級別的錯誤：error?(當(dāng)被觸發(fā)的時候，程序會退出)

Globals-配置額外的全局變量

啟用ESLint規(guī)則后，當(dāng)訪問當(dāng)前源文件內(nèi)未定義的變量時，no-undef 規(guī)則將發(fā)出警告。
而有時候，我們是需要在其他文件訪問一些全局變量的，且保證能正常取到值。這時可以在 ESLint 中定義這些全局變量，這樣 ESLint 就不會發(fā)出警告了。

• 用注釋指定全局變量，格式如下：

/*?global?var1,?var2?*/
復(fù)制代碼

這定義了兩個全局變量，var1?和?var2。如果你想選擇性地指定這些全局變量可以被寫入(而不是只被讀取)，那么你可以用一個?"writable"?的標(biāo)志來設(shè)置它們:

/*?global?var1:writable,?var2:writable?*/
復(fù)制代碼

• 配置文件中通過globals?配置屬性設(shè)置，對于每個全局變量鍵，將對應(yīng)的值設(shè)置為?"writable"?以允許重寫變量，或?"readonly"?不允許重寫變量。例如：

//?.eslintrc.js
"globals":?{
??"var1":?"writable",
??"var2":?"readonly"
}
復(fù)制代碼

Environments - 指定腳本的運行環(huán)境

每種環(huán)境都有一組特定的預(yù)定義全局變量。如brower、node環(huán)境變量、es6環(huán)境變量等。

'env':?{
??'browser':?true,
??'commonjs':?true,
??'es6':?true
},
復(fù)制代碼

Plugins - 第三方插件

ESLint 支持使用第三方插件，先在項目中下載安裝要引入的插件，配置文件中使用?plugins?關(guān)鍵字來存放插件名字的列表。插件名稱可以省略?eslint-plugin-?前綴。

?plugins:?['react',?'babel'],?//?eslint-plugin-react?eslint-plugin-babel
復(fù)制代碼

Extends - 繼承

一個配置文件可以被基礎(chǔ)配置中的已啟用的規(guī)則繼承。

?extends:?["eslint:recommended","plugin:prettier/recommended"],
復(fù)制代碼

配置代碼注釋方式

有時候，我們需要在代碼中忽略ESLint的某些規(guī)則檢查，此時我們可以通過加入代碼注釋的方式解決：可以指定整個文件、某一行、某一區(qū)塊開啟/關(guān)閉 某些或全部規(guī)則檢查；

/*?eslint-disable?*/????--禁用全部規(guī)則??放在文件頂部則整個文件范圍都不檢查
/*?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)前項目中或全局環(huán)境下，但因項目間存在的差異性，我們一般會將它安裝在當(dāng)前項目中。安裝：

yarn?add?--save-dev?eslint
復(fù)制代碼

安裝插件和解析器

假如項目中使用了TypeScript和React，則安裝：

//?我們需要安裝?@typescript-eslint/parser，替代掉默認(rèn)的Espree解析器。
yarn?add?--save-dev?typescript?@typescript-eslint/parser

//?安裝eslint-plugin-react配置包擴展支持React語法；安裝@typescript-eslint/eslint-plugin提供額外的ts 語法的規(guī)則
yarn?add?--save-dev?eslint-plugin-react?@typescript-eslint/eslint-plugin
復(fù)制代碼

其他的插件和解析器請根據(jù)實際項目需要安裝。

創(chuàng)建配置文件

我們在項目的根目錄下創(chuàng)建一個?.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)建適合自己及團隊的規(guī)則配置。
通過研究他人優(yōu)秀的規(guī)則集，慢慢地構(gòu)建自用或公司的規(guī)則配置；

本篇文章介紹的ESLint只是涉及的一些重要的概念及基本使用。ESLint規(guī)則及配置包含了很多的內(nèi)容，想要用的好，值得花精力自行好好研究。

Q&A

1. 如何方便地開始使用ESLint，而且盡量不改動以前的代碼？

如果你正在使用GIt做項目代碼管理，那么則可以借助husky + lint-staged + Prettier 在Git提交時，自動強制校驗并格式化且修復(fù)代碼，而且只處理自己本次改動提交的文件。

采用這種pre-commit階段增量校驗的模式，盡量避免對老舊代碼的影響；這種方式可以穩(wěn)健地逐步完善老項目；

2. 如何解決Prettier與ESLint的配置沖突問題？

在代碼格式化時采用Perttier規(guī)則，而我們代碼校驗使用的是ESLint，如果同一個規(guī)則配置不一致，往往就會出現(xiàn)沖突問題；

比如：字符串單、雙引號的配置，eslint fix后把字符串變成單引號，再次編輯文件后，保存（Prettier）自動格式化后卻又變成雙引號，導(dǎo)致代碼校驗異常。

解決方式一：要么修改 eslintrc，要么修改 prettierrc 配置，讓它們配置保持一致；

解決方式二：禁用 ESLint中和Prettier配置有沖突的規(guī)則；再使用 Prettier 來替代 ESLint 的格式化功能；
安裝eslint-config-prettier插件配置集，把其配置到eslintrc規(guī)則的尾部。執(zhí)行ESLint命令，會禁用那些和Prettier配置有沖突的規(guī)則。
安裝eslint-plugin-prettier插件，先使用Prettier對代碼進行格式化，再并對不一致的地方進行標(biāo)記；
這兩個包配合使用，可以達到運行?eslint \--fix?時，采用Prettier的配置規(guī)則 來格式化文件。

具體配置及使用方式，請自行查閱探索；

總結(jié)

ESLint、Prettier、EditorConfig的引入，需要犧牲一些開發(fā)人員的編碼自由，來保證團隊成員代碼風(fēng)格的一致性，進而提高代碼的可讀性、可維護性。使項目更好管理，成員之間合作更順暢。

就算不從團隊開發(fā)考慮，個人從中也能逐漸建立良好的開發(fā)規(guī)范，對于自己的成才也是長久的。

當(dāng)然，我們也該清楚地認(rèn)識到工具的局限性：

一、清楚定位：
ESLint等解決的是團隊開發(fā)規(guī)范的問題，并不能解決其他諸如編碼能力、代碼合理性等問題， 還屬于工程化中比較弱的一環(huán)。

有時會遇到團隊制定特別嚴(yán)格的規(guī)則校驗，且在每次代碼提交時，收集檢查結(jié)果作為代碼質(zhì)量評估的重要指標(biāo)。個人認(rèn)為這種方式固然可以量化一部分代碼質(zhì)量考核問題 ，但形式主義過重。不過也是廖勝于無的做法。

1. 太過嚴(yán)格的規(guī)則，限制了代碼的靈活性。每一個規(guī)則都應(yīng)該是可被討論，具體開啟與否應(yīng)該視團隊而定；
2. 語言或框架某個寫法如果是被嚴(yán)禁使用的，那它就應(yīng)該在源頭被消滅；之所以存在肯定有一定的意義的；
3. ESLint不是神藥，最佳代碼實踐往往在于多多探索，持續(xù)更新；

二、技術(shù)革新快速，之前認(rèn)為的準(zhǔn)則不一定就適用于當(dāng)下，要保持持續(xù)調(diào)整的心態(tài)和跟進優(yōu)化的行動力；

三、不要作嚴(yán)格代碼規(guī)范的強迫癥患者， 它并不是目的，只是一個讓我們更方便管理項目，從復(fù)雜團隊項目解脫出來的一個方式。

更傾向的做法是：不要完全依賴工具的規(guī)則校驗，要讓它們幫忙我們養(yǎng)成良好的編碼習(xí)慣，培養(yǎng)代碼質(zhì)量意識，指引我們寫出更優(yōu)的代碼，而不是依賴它