大家好，我卡頌。

配置過代碼格式化的同學一定糾結過如下問題：Eslint和Prettier都能格式化代碼風格，是單用Eslint，還是兩個一起用呢？

從今以后，你再也不用糾結這個問題，因為Eslint團隊已經妥協了 —— 根據官方博客[1]所說，從v8.53.0起，Eslint中「代碼風格相關規則」將被棄用。

有意思的是，造成上述局面的原因并不是技術問題導致的，更多是市場行為。

本文讓我們聊聊事情的來龍去脈。

Eslint的崛起

在2013年之前，前端工程師通常使用JSLint或JSHint作為「代碼檢查器」，用以檢測：

代碼質量問題

比如：應該避免使用 eval()，應該使用===而不是==...

代碼中的錯誤

比如：未定義的變量、類型轉換的問題...

其中，JSLint基于內部實現的JS解析器，對生成的token流（詞法單元流）進行分析，檢查代碼語法。

JSHint是從JSLint派生出來的，他們工作原理類似，但JSHint更靈活 —— 他提供了.jshintrc配置文件方便開發者自定義規則。

上述兩個工具都能檢查代碼，但由于實現原理的限制，沒法進行復雜的規則檢查。同時，他們對「代碼風格」的檢查也較少。

在這一時期，「代碼風格檢查」（比如：縮進、行長度、引號類型、是否在語句末尾使用分號...）主要交給JSCS。

2013年，Eslint問世。他將代碼解析為AST并分析：

• 相比于JSHint或JSLint的實現，AST保留了更多代碼上下文信息。

所以，Eslint不僅可以進行更復雜的規則校驗，還能讓開發者以插件的形式自己編寫規則。

• 相比于JSCS，Eslint支持「代碼自動修復」

所以，Eslint不僅能對代碼風格提出建議，還能自動修復「不符合規范的風格」。

更先進的功能，再加上作者身份加持（作者是紅寶書作者），使得Eslint逐漸淘汰了上述競品。

Eslint與Prettier之爭

雖然Eslint提供了大量規則，但并不是所有開發者都想配置一套自己的規則集。

慢慢的，一些「Eslint規則集的最佳實踐」被提出（比如Airbnb規則[2]、standard規則[3]）。

開發者通常會在這些規則集的基礎上再做些個性化修改，組成項目的lint規則集。

這些規則集中，通常包含三類規則：

• 代碼質量檢查
• 代碼錯誤檢查
• 代碼風格檢查

其中「代碼風格檢查」通常是非常主觀的。如果團隊成員的「代碼風格檢查規則」配置不一樣，很影響提交時git diff的可讀性。

為了強制規范「代碼風格檢查」，Prettier出現了。這是一款「固執己見」的代碼風格格式化工具，他集成了一套代碼風格，并且可配置程度不高。

「可配置程度不高」是一把雙刃劍，一方面，他能強制規范團隊成員的代碼風格。

但另一方面，如果想對代碼風格做些個性化設置，Prettier很有可能不支持。

舉個例子（來自為什么我不使用 Prettier中的例子），Prettier中通過printWidth屬性配置「一行可以顯示的字符數」，超過就會折行。

有時候我們并不需要「超過某個字符數就折行」，因為在Git Diff時，折行會破壞Diff信息的可讀性：

然而遺憾的是，Prettier并沒有提供配置關閉這一行為。

基于上述原因，出現了兩種解決方案：

方案1  Eslint與Prettier配合使用

其中Eslint負責代碼質量、錯誤檢查，Prettier負責代碼風格檢查。優點是能夠滿足代碼質量、風格檢查。缺點是：

• Eslint與Prettier規則可能沖突，配置成本高。
• 代碼風格檢查的可配置性低（Prettier配置性低）。

方案2 只使用Eslint

使用「代碼風格相關規則的集合」，比如@stylistic/eslint-plugin-js[4]管理代碼風格。再使用其他規則管理代碼質量。

這種方式優點明顯 —— 可配置性高，且配置簡單（只需要配置Eslint）。

顯然，方案2是優于方案1的。既然如此，Eslint團隊為什么要棄用所有「代碼風格相關規則」呢？

Eslint團隊的妥協

設想一下，每當出現新的語言特性，與該特性相關的規則包括：

• 少量的代碼質量相關規則
• 少量的代碼錯誤相關規則
• 各種奇怪的代碼風格規則

顯然前兩者的優先級、重要性都高于第三者。如果說，在Eslint成長初期，為了收割JSCS的用戶，Eslint必須實現所有「JSCS支持的代碼風格規則」，此時實現各種代碼風格規則是必要的。

但今時今日，Eslint早已成為JS領域「代碼檢查器」的老大，不需要再為了市場份額努力滿足社區的一切需要。況且，有些時候，考慮「規則沖突」以及「一致性」，有些需求甚至無法滿足。

規則沖突

最理想的情況，所有核心規則都能很好地相互配合，這意味著沒有兩個規則應該標記同一個問題，也不會有任何兩個核心規則給出相互沖突的建議。

當核心規則少于30條時，這很容易。但對于越來越多的規則，這很難做到。

一致性問題

ESLint規則之間是無法互相訪問的。這意味著我們會遇到無法正確修復錯誤的問題，因為信息可能位于另一個規則中。

舉個例子，如果自動修復需要添加新的代碼行，就需要知道文件是如何縮進的，以便應用正確的修復。但是，規則indent控制ESLint的縮進，這意味著其他規則需要在不縮進的情況下應用修復，然后相信indent規則將在后續傳遞中修復縮進。

總結

ESLint從v8.53.0起，將棄用「代碼風格相關規則」。這么做主要是因為繼續維護「代碼風格相關規則」對核心團隊來說，投入產出比太低。

試想一下，核心團隊花費大力氣解決問題（規則沖突、一致性問題），推出新的「代碼風格規則」，開發者會感謝Eslint核心團隊的付出么？

不會的，這些「代碼風格規則」會被集成到規則集中，并被冠以「某種開發理念」兜售給開發者（比如Airbnb規范）。

實際收獲名利的是站在臺前的「宣傳開發理念的團隊」，而背后辛苦干活的Eslint核心團隊往往被忽略了，換你你樂意么？

參考資料

[1]官方博客:https://eslint.org/blog/2023/10/deprecating-formatting-rules/。

[2]Airbnb規則:https://airbnb.io/javascript/。

[3]standard規則:https://standardjs.com/。

[4]@stylistic/eslint-plugin-js:https://www.npmjs.com/package/@stylistic/eslint-plugin-js。