前言
? ? ? ?團隊多人協同開發項目，困擾團隊管理的一個很大的問題就是：無可避免地會出現每個開發者編碼習慣不同、代碼風格迥異，為了代碼高可用、可維護性，需要從項目管理上盡量統一和規范代碼。理想的方式需要在項目工程化方面，借助可靈活配置的工具自動化解決。
? ? ? ?而現在無論是開源項目還是成熟的團隊項目，根目錄下出現了越來越多的配置文件，這是前端項目在快速演變、逐漸完善健壯的一種表現，那面對這些配置文件，如果是一臉懵的狀態，傻傻分不清楚不太行。
? ? ?本篇文章便來介紹跟編碼風格、代碼規范相關的幾個場景的配置功能：
? ? ?ESLint、Prettier、EditorConfig
? ? ?借助于EditorConfig+Prettier+ESLint 的組合，項目中通過統一約定配置，可以在團隊成員在代碼開發過程中就檢查、約束、美化代碼，統一編碼風格；且可以省去很多的溝通成本，提前暴露代碼缺陷，減少后期二次修改代碼的風險。
EditorConfig
EditorConfig包含的內容比較少，主要是配置我們的編輯器，編寫代碼時的簡單規則，不足以滿足項目更多需求；
ESLint
ESLint 是一個在 JavaScript 代碼中通過規則模式匹配作代碼識別和報告的插件化的檢測工具，它的目的是保證代碼規范的一致性和及時發現代碼問題、提前避免錯誤發生。
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(已停止維護)
但自2019 年 1 月起，根據 TSLint 的官方聲明，TSLint 正在慢慢被廢棄，并會逐步遷移到 ESLint作為代碼檢查的工具。至于停止維護的原因：一是ESLint社區更活躍、越來越完善，且社區對ESLint的擁護聲浪越來越高，相反TSLint則完善度不夠；二是在持續迭代、支持新特性的過程中發現TSLint 的規則運作方式存在架構性的性能問題，相反的 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
遇到項目內有多個層疊配置時，采用就近原則作為高優先級；
Prettier
Prettier是一個誕生于2016年就迅速流行起來的專注于代碼格式化的工具。出道即巔峰。Prettier只關注格式化，并不具有lint檢查語法等能力。它通過解析代碼并匹配自己的一套規則，來強制執行一致的代碼展示格式。它在美化代碼方面有很大的優勢，配合ESLint可以對ESLint格式化基礎上做一個很好的補充。
VSCode內置的代碼格式化工具可以指定為由Prettier接管，此時右下角會顯示為Prettier。可以自行配置格式化觸發機制：換行時格式化、保存文件時格式化、還是自行快捷鍵觸發；
配置項
在VSCode 首選項-設置-擴展或.settings.json中更改通用配置；
在具體項目根目錄設置.prettierrc.js單獨配置；
module.exports = {// 一行最多 120 字符printWidth: 120,// 使用 2 個空格縮進tabWidth: 2,// 不使用縮進符，而使用空格useTabs: false,// 行尾需要有分號semi: false,// 使用單引號singleQuote: true,// 對象的 key 僅在必要時用引號quoteProps: 'as-needed',// jsx 不使用單引號，而使用雙引號jsxSingleQuote: false,// 末尾需要有逗號trailingComma: 'none',// 大括號內的首尾需要空格bracketSpacing: true,// jsx 標簽的反尖括號需要換行jsxBracketSameLine: false,// 箭頭函數，只有一個參數的時候，也需要括號arrowParens: 'always',// 每個文件格式化的范圍是文件的全部內容rangeStart: 0,rangeEnd: Infinity,// 不需要寫文件開頭的 @prettierrequirePragma: false,// 不需要自動在文件開頭插入 @prettierinsertPragma: false,// 使用默認的折行標準proseWrap: 'preserve',// 根據顯示樣式決定 html 要不要折行htmlWhitespaceSensitivity: 'css',// vue 文件中的 script 和 style 內不用縮進vueIndentScriptAndStyle: false,// 換行符使用 lfendOfLine: 'lf',// 格式化嵌入的內容embeddedLanguageFormatting: 'auto',// html, vue, jsx 中每個屬性占一行singleAttributePerLine: false
}
格式化的生效策略同樣是就近原則，一步步匹配目標文件最近父目錄的配置文件，越近優先級越高。
總結
1、在代碼格式化時采用Perttier規則，在代碼校驗時使用ESLint
2、遇到項目內有多個層疊配置時，采用就近原則作為高優先級
3、ESLint等解決的是團隊開發規范的問題，并不能解決其他諸如編碼能力、代碼合理性等問題， 還屬于工程化中比較弱的一環。
- EditorConfig 是用來抹平編輯器差異的，比如文件編碼，鎖進格式等
- ESLint 關注于代碼質量校驗 和 代碼格式校驗，配合插件支持autoFix和錯誤提示，完全可插拔
- Prettier Prettier只關注代碼格式，也支持自動修復，規則和ESLint不同
Q&A
如何解決Prettier與ESLint的配置沖突問題？
解決方式一：要么修改 eslintrc，要么修改 prettierrc 配置，讓它們配置保持一致；
解決方式二：禁用 ESLint中和Prettier配置有沖突的規則；再使用 Prettier 來替代 ESLint 的格式化功能；
)
