授權轉載自：nowThen

https://juejin.cn/post/6895889063111294990

前言

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

• [x] 文檔約定 - 諄諄教導，自求多福？

• [x] 經常性CodeRevice - 苦口婆心，耳提面命？

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

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

今天，我們就來分析一下跟編碼風格、代碼規范相關的、、這幾個常見配置功能。

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

簡單歸納：

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

當然，他們各有適用范圍，接下來，我們就來一探究竟，重點關注ESLint。

EditorConfig

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

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

解讀

依賴編輯器IDE的支持

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

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

支持多種文件格式

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

就近原則

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

配置文件?.editorconfig

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

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

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

更多內容可以訪問官網查看。

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

Prettier

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

那么如何使用呢？

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

與ESLint等配合使用；在下文ESLint中詳細談，此處不予贅述；

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

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

本人的使用習慣是用快捷鍵手動觸發格式化。

當在編輯器里格式化未生效時，可以在.settings.json里檢查對應文件格式指定的格式化程序并調整就可以：這樣在VSCode編輯器里，觸發文件格式化時就能根據配置自動美化格式代碼；

配置項：

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

比如以下一些配置：

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

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

ESLint

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

我們跟著ESLint官網的說明，來理解ESLint。

Lint發展歷程

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

JavaScript發展歷程中出現的Lint工具：JSLint->JSHint->ESLint/TSLint；

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

關于TSLint(已停止維護)

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

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

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

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

那么ESLint出現的意義是什么？

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

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

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

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

總結一下ESLint的作用及優勢：

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

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

• 統一團隊代碼風格

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

• 確保代碼遵循最佳實踐

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

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

ESLint特點

一、ESLint 的所有規則都被設計成可插拔的

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

二、ESLint是完全可配置的

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

三、ESLint 使用 Node.js 編寫

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

四、ESLint解析時將源碼先轉換成AST

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

支持的配置文件格式

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

• JavaScript?- 使用?.eslintrc.js?然后輸出一個配置對象。
• YAML?- 使用?.eslintrc.yaml?或?.eslintrc.yml?去定義配置的結構。
• JSON?- 使用?.eslintrc.json?去定義配置的結構，ESLint 的 JSON 文件允許 JavaScript 風格的注釋。
• (棄用)?- 使用?.eslintrc，可以使 JSON 也可以是 YAML。
• package.json?- 在?package.json?里創建一個?eslintConfig屬性，在那里定義你的配置。

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

.eslintrc.js

.eslintrc.yaml

.eslintrc.yml

.eslintrc.json

.eslintrc

package.json

遇到項目內有多個層疊配置時，依然采用就近原則作為高優先級；

配置文件說明

Rules-啟用的規則及其各自的錯誤級別

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

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

Globals-配置額外的全局變量

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

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

/*?global?var1,?var2?*/
復制代碼

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

/*?global?var1:writable,?var2:writable?*/
復制代碼

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

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

Environments - 指定腳本的運行環境

每種環境都有一組特定的預定義全局變量。如brower、node環境變量、es6環境變量等。

'env':?{
??'browser':?true,
??'commonjs':?true,
??'es6':?true
},
復制代碼

Plugins - 第三方插件

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

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

Extends - 繼承

一個配置文件可以被基礎配置中的已啟用的規則繼承。

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

配置代碼注釋方式

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

/*?eslint-disable?*/????--禁用全部規則??放在文件頂部則整個文件范圍都不檢查
/*?eslint-disable?no-alert,?no-console?*/??--禁用某些規則
//?eslint-disable-line?????--當前行上禁用規則
//?eslint-disable-next-line?--下一行上禁用規則
復制代碼

具體參考：eslint.bootcss.com/docs/user-g…；

使用ESLint

安裝 ESLint

ESLint 可以安裝在當前項目中或全局環境下，但因項目間存在的差異性，我們一般會將它安裝在當前項目中。安裝：

yarn?add?--save-dev?eslint
復制代碼

安裝插件和解析器

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

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

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

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

創建配置文件

我們在項目的根目錄下創建一個?.eslintrc.js，內容如下：

module.exports?=?{
????parser:?'@typescript-eslint/parser',
????plugins:?['react','@typescript-eslint'],
????rules:?{
????????//?禁止使用?var
????????'no-var':?"error",
????????//?優先使用?interface?而不是?type
????????'@typescript-eslint/consistent-type-definitions':?[
????????????"error",
????????????"interface"
????????]
????}
}
復制代碼

站在巨人的肩膀上使用

前端社區中有很多比較好的規則集，我們要做的是站在巨人的肩膀上，基于已有規則集，構建適合自己及團隊的規則配置。
通過研究他人優秀的規則集，慢慢地構建自用或公司的規則配置；

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

Q&A

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

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

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

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

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

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

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

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

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

總結

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

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

當然，我們也該清楚地認識到工具的局限性：

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

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

太過嚴格的規則，限制了代碼的靈活性。每一個規則都應該是可被討論，具體開啟與否應該視團隊而定；

語言或框架某個寫法如果是被嚴禁使用的，那它就應該在源頭被消滅；之所以存在肯定有一定的意義的；

ESLint不是神藥，最佳代碼實踐往往在于多多探索，持續更新；

二、技術革新快速，之前認為的準則不一定就適用于當下，要保持持續調整的心態和跟進優化的行動力；

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

更傾向的做法是：不要完全依賴工具的規則校驗，要讓它們幫忙我們養成良好的編碼習慣，培養代碼質量意識，指引我們寫出更優的代碼，而不是依賴它

最后

歡迎關注「前端瓶子君」，回復「交流」加入前端交流群！歡迎關注「前端瓶子君」，回復「算法」自動加入，從0到1構建完整的數據結構與算法體系！另外，每周還有手寫源碼題，瓶子君也會解答喲！》》面試官也在看的算法資料《《“在看和轉發”就是最大的支持

總結

以上是生活随笔為你收集整理的eslint 保存自动格式化_代码规范之理解ESLint、Prettier、EditorConfig的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。