大家好,我卡頌。
配置過代碼格式化的同學一定糾結過如下問題:Eslint和Prettier都能格式化代碼風格,是單用Eslint,還是兩個一起用呢?
從今以后,你再也不用糾結這個問題,因為Eslint團隊已經妥協了 —— 根據官方博客[1]所說,從v8.53.0起,Eslint中「代碼風格相關規則」將被棄用。
有意思的是,造成上述局面的原因并不是技術問題導致的,更多是市場行為。
本文讓我們聊聊事情的來龍去脈。
在2013年之前,前端工程師通常使用JSLint或JSHint作為「代碼檢查器」,用以檢測:
比如:應該避免使用 eval(),應該使用===而不是==...
比如:未定義的變量、類型轉換的問題...
其中,JSLint基于內部實現的JS解析器,對生成的token流(詞法單元流)進行分析,檢查代碼語法。
JSHint是從JSLint派生出來的,他們工作原理類似,但JSHint更靈活 —— 他提供了.jshintrc配置文件方便開發者自定義規則。
上述兩個工具都能檢查代碼,但由于實現原理的限制,沒法進行復雜的規則檢查。同時,他們對「代碼風格」的檢查也較少。
在這一時期,「代碼風格檢查」(比如:縮進、行長度、引號類型、是否在語句末尾使用分號...)主要交給JSCS。
2013年,Eslint問世。他將代碼解析為AST并分析:
所以,Eslint不僅可以進行更復雜的規則校驗,還能讓開發者以插件的形式自己編寫規則。
所以,Eslint不僅能對代碼風格提出建議,還能自動修復「不符合規范的風格」。
更先進的功能,再加上作者身份加持(作者是紅寶書作者),使得Eslint逐漸淘汰了上述競品。
雖然Eslint提供了大量規則,但并不是所有開發者都想配置一套自己的規則集。
慢慢的,一些「Eslint規則集的最佳實踐」被提出(比如Airbnb規則[2]、standard規則[3])。
開發者通常會在這些規則集的基礎上再做些個性化修改,組成項目的lint規則集。
這些規則集中,通常包含三類規則:
其中「代碼風格檢查」通常是非常主觀的。如果團隊成員的「代碼風格檢查規則」配置不一樣,很影響提交時git diff的可讀性。
為了強制規范「代碼風格檢查」,Prettier出現了。這是一款「固執己見」的代碼風格格式化工具,他集成了一套代碼風格,并且可配置程度不高。
「可配置程度不高」是一把雙刃劍,一方面,他能強制規范團隊成員的代碼風格。
但另一方面,如果想對代碼風格做些個性化設置,Prettier很有可能不支持。
舉個例子(來自為什么我不使用 Prettier中的例子),Prettier中通過printWidth屬性配置「一行可以顯示的字符數」,超過就會折行。
有時候我們并不需要「超過某個字符數就折行」,因為在Git Diff時,折行會破壞Diff信息的可讀性:
然而遺憾的是,Prettier并沒有提供配置關閉這一行為。
基于上述原因,出現了兩種解決方案:
其中Eslint負責代碼質量、錯誤檢查,Prettier負責代碼風格檢查。優點是能夠滿足代碼質量、風格檢查。缺點是:
使用「代碼風格相關規則的集合」,比如@stylistic/eslint-plugin-js[4]管理代碼風格。再使用其他規則管理代碼質量。
這種方式優點明顯 —— 可配置性高,且配置簡單(只需要配置Eslint)。
顯然,方案2是優于方案1的。既然如此,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。
本文鏈接:http://www.tebozhan.com/showinfo-26-16023-0.htmlEslint團隊終于妥協了...
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
下一篇: 通過實例理解Web應用用戶密碼存儲方案