www日本黄色,最新中文字幕av,三级久久久久久,音影先锋成人资源站,免费看一级高潮毛片,av片电影在线播放,国产伦精品一区二区三区四区视频 ,黄色一级在线视频

前端Q

我是winty，專注分享前端知識和各類前端資源，樂于分享各種有趣的事，關(guān)注我，一起做個有趣的人～

公眾號

點擊上方前端Q，關(guān)注公眾號

回復(fù)加群，加入前端Q技術(shù)交流群

ESLint 是一款提高代碼質(zhì)量的靜態(tài)分析工具，旨在使代碼風(fēng)格更加一致并避免錯誤。

ESLint 主要包括兩大類規(guī)則：代碼質(zhì)量規(guī)則和格式化規(guī)則。不幸的是，以后 ESLint 有且僅有代碼質(zhì)量規(guī)則了......

2023 年 ESLint 8.53 中，ESLint 官宣廢除所有格式化規(guī)則，使用此類規(guī)則會收到警告。在官方博客中，ESLint 團隊提及 ESLint 10 可能會完全廢除所有規(guī)則，而目前最新的 ESLint 主版本已經(jīng)到達 ESLint 9.2 了。

本期一起來回顧 ESLint 廢除格式化規(guī)則的諸多幕后原因和技術(shù)細(xì)節(jié)，以及為什么這是 ESLint 團隊篤信的正確選擇。

背景

2013 年 ESLint 首發(fā)時，JS 生態(tài)系統(tǒng)陷入了關(guān)于源碼格式化是否應(yīng)該成為 linter 一部分的爭論。

JSLint 是地球上第一個 JS linter，“JSLint 之父”將其格式首選項大量編碼到 JSLint 中。這些風(fēng)格偏好在 JSLint 的繼任者 JSHint 中得到了延續(xù)和松耦。

但 2013 年，JSHint 宣布廢除格式化選項，且會在下一個主版本中刪除它們。雖然這些選項從未被刪除，但它們?nèi)詴故揪妫?/p>

警告：格式化選項已被廢除，且會在下一個主版本中刪除。JSHint 將其作用域限制在代碼準(zhǔn)確性的問題上。如果你想強制執(zhí)行源碼格式化規(guī)則，請傳送到 JSCS 項目。

JSCS 項目的誕生旨在滿足 JS 開發(fā)者日益增長的愿望，更精準(zhǔn)地格式化開發(fā)者的代碼。ESLint 出現(xiàn)同段實驗期，用戶嘗試使用 JSHint、JSCS 和 ESLint 的不同組合來實現(xiàn)它們的 linting 和格式化需求。

早期，我認(rèn)為 ESLint 與 JSHint 分庭抗禮的唯一方式在于，確保所有可用的 JSHint 規(guī)則都有 ESLint 版本的等效功能。

雖然 ESLint 從古至今的優(yōu)勢一直是創(chuàng)建自定義規(guī)則，但我認(rèn)為如果每個人都必須自己重建 JSHint 規(guī)則，ESLint 勢必不會得到大規(guī)模采用。我最初的計劃是制定幾十條核心規(guī)則，然后將其余規(guī)則作為插件來實現(xiàn)。

隨著時間的推移，ESLint 收到越來越多向核心源碼添加格式化規(guī)則的需求。許多需求提到它們不想在代碼中同時使用兩種工具：ESLint + JSCS，如果 ESLint 可以完成 JSCS 的功能，它們可以果斷棄用 JSCS，且只使用 ESLint。

因此，現(xiàn)在 ESLint 有一個團隊，我們關(guān)注實現(xiàn)等價功能來支持這種用戶場景。最終，我們的工作十分出色，JSCS 的使用率下降了，我們將 JSCS 合并到了 ESLint。

那時我們還太年輕，不知道 JSHint 的想法是正確的，盡管 ESLint 已經(jīng)成為 JS 的主流 linter 和源碼格式化程序，但我們涉及了太多工作。

JS 技術(shù)爆炸和維護負(fù)擔(dān)

在 ES6 和 React 發(fā)展的推動下，大家編寫 JS 的方式今非昔比。Airbnb 和 Standard 等人氣爆棚的風(fēng)格指南鼓勵 JS 開發(fā)者精確掌握其代碼的優(yōu)雅編寫方式。

結(jié)果，ESLint 被關(guān)于格式化規(guī)則的例外和選項的需求淹沒了。

在過去十年里，我們見證了各種奇葩的代碼風(fēng)格，并伴隨著在 ESLint 核心規(guī)則中強制執(zhí)行它們的需求。每次引入 ES6 新語法時，我們都會收到一系列更新現(xiàn)有規(guī)則和實施新規(guī)則的需求。

當(dāng)我們的核心規(guī)則接近 300 條時，我們試圖通過凍結(jié)風(fēng)格規(guī)則來減輕維護負(fù)擔(dān)，這樣我們就不再追逐極端情況，以此支持用戶的個人偏好。這有所幫助，但還不夠。

規(guī)則沖突。用戶期望核心規(guī)則能夠“夢幻聯(lián)動”，這意味著,任意兩個規(guī)則都不應(yīng)標(biāo)記相同的問題，任意兩個核心規(guī)則也不應(yīng)給出相互沖突的建議。雖然當(dāng)核心規(guī)則少于 30 條時，這輕而易舉，但當(dāng)規(guī)則超過 300 條時，這就難如脫單，甚至是不可能事件。
不切實際的期望。有了大量的核心格式規(guī)則，用戶期望每一種可能的樣式指南都應(yīng)該只使用核心規(guī)則就可以實現(xiàn)，而無需涉及插件。這讓 ESLint 團隊雪上加雪，要求它們繼續(xù)添加選項，這也增加了 ESLint 核心源碼的規(guī)模。
努力 vs 價值錯位。不斷添加新選項和例外，支持用戶的風(fēng)格指南的維護重?fù)?dān)壓在了 ESLint 團隊身上，而價值卻只被少數(shù)用戶提取。
機會成本。我們花在維護格式化規(guī)則上的時間越多，花在對大量用戶有利的事情上的時間就越少。
索然無趣。雖然 ESLint 受益于外部貢獻，但這些貢獻者對糾結(jié)空格等極端情況不感興趣。ESLint 團隊本身認(rèn)為這些規(guī)則的優(yōu)先級遠遠低于任何其他工作，這常常使問題長時間懸而未決。
一致性問題。由于 ESLint 的規(guī)則被設(shè)計為原子性，且無法訪問其他規(guī)則，因此我們會遭遇無法正確修復(fù)錯誤的問題，因為信息位于另一個規(guī)則中。舉個栗子，如果自動修復(fù)需要添加新的代碼行，則需要知道文件如何縮進才能應(yīng)用正確的修復(fù)。但是，indent 規(guī)則控制 ESLint 的縮進，這意味著，其他規(guī)則需要應(yīng)用不帶縮進的修復(fù)，然后相信 indent 規(guī)則將在后續(xù)傳遞中修復(fù)縮進。

隨著 ESLint 朽化，這些問題與日俱增，我們終于遭遇了壓死駱駝的最后一根稻草。

所有源碼格式化規(guī)則將在 ESLint 8.53 的下一個版本中廢除，但至少要等到 ESLint 10 才會被刪除。盡管你可能會在 ESLint CLI 中親眼目睹廢除的警告，但你還可以繼續(xù)使用它們。

你該怎么辦

我們建議使用源碼格式化程序，而不是訴諸 ESLint 來格式化代碼。源碼格式化程序旨在理解整個文件，并在整個文件中應(yīng)用一致的格式。

雖然你可能無法像 ESLint 那樣對異常有大量的控制，但與使用數(shù)十個單獨的規(guī)則配置 ESLint 相比，你將獲得簡單性和速度的權(quán)衡。

我們推薦下列兩種格式化程序：

Prettier：基于 JS 的格式化程序，支持多語言格式化
dprint：基于 Rust 的格式化程序，支持迷你的語言集

如果你對使用專用源碼格式化程序的想法不感興趣，你還可以使用針對 JS 的 @stylistic/eslint-plugin-js 或針對 TS 的 @stylistic/eslint-plugin-ts。這些 npm 包分別包含 ESLint 核心和 typescript-eslint 中廢除的格式規(guī)則。

這些軟件包由 AntFu 維護，他決定繼續(xù)維護這些規(guī)則。如果你想繼續(xù)使用 ESLint 的源碼格式化規(guī)則，那么我們建議切換到這些軟件包。