大家好，我卡頌。

你所需要的網(wǎng)站建設(shè)服務(wù)，我們均能行業(yè)靠前的水平為你提供.標(biāo)準(zhǔn)是產(chǎn)品質(zhì)量的保證，主要從事成都做網(wǎng)站、網(wǎng)站制作、企業(yè)網(wǎng)站建設(shè)、手機網(wǎng)站制作、網(wǎng)頁設(shè)計、高端網(wǎng)站設(shè)計、網(wǎng)頁制作、做網(wǎng)站、建網(wǎng)站。成都創(chuàng)新互聯(lián)擁有實力堅強的技術(shù)研發(fā)團隊及素養(yǎng)的視覺設(shè)計專才。

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

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

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

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

Eslint的崛起

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

代碼質(zhì)量問題

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

代碼中的錯誤

比如：未定義的變量、類型轉(zhuǎn)換的問題...

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

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

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

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

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

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

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

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

所以，Eslint不僅能對代碼風(fēng)格提出建議，還能自動修復(fù)「不符合規(guī)范的風(fēng)格」。

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

Eslint與Prettier之爭

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

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

開發(fā)者通常會在這些規(guī)則集的基礎(chǔ)上再做些個性化修改，組成項目的lint規(guī)則集。

這些規(guī)則集中，通常包含三類規(guī)則：

• 代碼質(zhì)量檢查
• 代碼錯誤檢查
• 代碼風(fēng)格檢查

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

為了強制規(guī)范「代碼風(fēng)格檢查」，Prettier出現(xiàn)了。這是一款「固執(zhí)己見」的代碼風(fēng)格格式化工具，他集成了一套代碼風(fēng)格，并且可配置程度不高。

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

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

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

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

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

基于上述原因，出現(xiàn)了兩種解決方案：

方案1  Eslint與Prettier配合使用

其中Eslint負責(zé)代碼質(zhì)量、錯誤檢查，Prettier負責(zé)代碼風(fēng)格檢查。優(yōu)點是能夠滿足代碼質(zhì)量、風(fēng)格檢查。缺點是：

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

方案2 只使用Eslint

使用「代碼風(fēng)格相關(guān)規(guī)則的集合」，比如@stylistic/eslint-plugin-js[4]管理代碼風(fēng)格。再使用其他規(guī)則管理代碼質(zhì)量。

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

顯然，方案2是優(yōu)于方案1的。既然如此，Eslint團隊為什么要棄用所有「代碼風(fēng)格相關(guān)規(guī)則」呢？

Eslint團隊的妥協(xié)

設(shè)想一下，每當(dāng)出現(xiàn)新的語言特性，與該特性相關(guān)的規(guī)則包括：

• 少量的代碼質(zhì)量相關(guān)規(guī)則
• 少量的代碼錯誤相關(guān)規(guī)則
• 各種奇怪的代碼風(fēng)格規(guī)則

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

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

規(guī)則沖突

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

當(dāng)核心規(guī)則少于30條時，這很容易。但對于越來越多的規(guī)則，這很難做到。

一致性問題

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

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

總結(jié)

ESLint從v8.53.0起，將棄用「代碼風(fēng)格相關(guān)規(guī)則」。這么做主要是因為繼續(xù)維護「代碼風(fēng)格相關(guān)規(guī)則」對核心團隊來說，投入產(chǎn)出比太低。

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

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

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

參考資料

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

[2]Airbnb規(guī)則:https://airbnb.io/javascript/。

[3]standard規(guī)則:https://standardjs.com/。

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

當(dāng)前題目：Eslint團隊終于妥協(xié)了...
文章源于：http://uogjgqi.cn/article/dpigdse.html