中興AX5400Pro+上手體驗：再升級 雙2.5G網口+USB 3.0這次全都有
2021年11月的時候，中興先后發布了兩款路由器產品，中興AX5400和中興AX5400 Pro，從產品命名上就不難看出這是隸屬于同一系列的，但在外觀設計上這兩款產品可以說是完全沒一點關系
ESLint 將在 11 月 3 日發布的 v8.53.0 版本中棄用代碼風格規則，也就是那些強制執行關于空格、分號、字符串格式等的代碼約定的規則。這樣，同時使用 ESlint 和 Prettier 時就不會出現沖突問題了！
ESlint 是一個代碼檢測工具，其可以進行代碼質量和代碼風格的靜態分析，捕獲潛在錯誤和不一致的編碼習慣。而 Prettier 是一個代碼格式化工具，其可以對代碼進行格式化，確保整個項目中的代碼風格保持一致。對于代碼中的一些問題，ESlint 可能無法正確格式化，這時候 Prettier 就可以很好地完成格式化的任務。因此，我們通常會組合使用 ESlint 和 Prettier，來保證代碼質量和風格統一（ ESlint 負責檢測代碼質量，Prettier 負責格式化代碼）。
但是兩者都有格式化代碼風格的規則，ESlint 將代碼進行格式化后，會重新被 Prettier 再次格式化。因此最終的格式化效果是 Prettier 提供的。而代碼校驗使用的是 ESLint，因此可能會出現沖突。ESlint 棄用代碼風格規則后就可以專注于監測代碼質量，而 Prettier 專注于監測代碼風格。
ESLint 于 2013 年發布，當時關于是否應該將源代碼格式化作為代碼規范工具的一部分是存在爭議的。JSLint 是最早出現的 JavaScript 代碼規范工具，將其作者的代碼格式化偏好編碼到了該工具中，這些偏好在 JSLint 的繼任者 JSHint 中有所保留。2013 年，JSHint 宣布他們將廢除與代碼風格相關的選項，并計劃在下一個主要版本中刪除它們。盡管這些選項從未被實際刪除，但 JSHint 仍然給出了此警告，提醒用戶該選項已被棄用：
Warning This option has been deprecated and will be removed in the next major release of JSHint。// 警告：此選項已被棄用，并將在 JSHint 的下一個主要版本中刪除。JSHint is limiting its scope to issues of code correctness. If you would like to enforce rules relating to code style, check out the JSCS project.// JSHint 將其范圍限制在代碼正確性問題上。如果你想強制執行與代碼風格相關的規則，請查看 JSCS 項目。JSCS 項目的誕生就是為了滿足 JavaScript 開發人員對代碼格式設置的日益具體化的需求。與 ESLint 同時出現的 JSCS 在早期曾經歷了一段試驗期，人們嘗試著使用不同組合的 JSHint、JSCS 和 ESLint 來滿足他們的格式化需求。
起初，ESLint 要想與 JSHint 合理競爭，就必須確保 ESLint 具備所有 JSHint 規則的等效功能。盡管 ESLint 的優勢在于自定義規則，但如果每個人都需要重新創建 JSHint 規則，ESLint 就可能無法得到廣泛采用。因此，最初的計劃是提供幾十個核心規則，將其余規則作為插件實現。
隨著時間的推移，ESLint 收到越來越多的請求，希望將格式和風格規則納入核心功能。許多請求都提到，他們不想使用兩個工具（ESLint 和 JSCS）來處理代碼，如果 ESLint 能夠實現 JSCS 的所有功能，他們可以放棄 JSCS，只使用 ESLint。因此，ESLint 團隊專注于實現功能的平衡，以滿足這種需求。最終，取得了巨大成功，JSCS 的使用量下降，并將其合并到了 ESLint 中。
當時，ESlint 團隊并沒有意識到 JSHint 的想法（棄用代碼風格規則）是正確的，盡管 ESLint 已經成為 JavaScript 的主導代碼規范工具。
在接下來的幾年里，尤其是在 ECMAScript 6 和 React 發展的推動下，編寫 JavaScript 的方式發生了巨大的變化。Airbnb 和 Standard 等越來越流行的風格指南鼓勵 JavaScript 開發人員更具體地了解他們的代碼是如何編寫的。因此，ESLint 收到了大量關于格式化規則的例外和選項的請求。在過去的十年中，出現了各種奇怪的代碼風格，并伴隨著對將它們強制應用于 ESLint 核心規則的請求。每當引入新的語法時，ESlint 團隊都會收到一系列請求，要求更新現有規則并實施新規則。
當 ESlint 的核心規則接近 300 條時，ESlint 團隊試圖通過凍結風格規則來減輕維護負擔，這樣就不再追蹤極端情況來支持每個人的個人偏好。這在一定程度上有所幫助，但還不夠：
所有這些問題隨著 ESLint 的發展而不斷增加，現在 ESlint 終究是到了一個無法跟上這些問題的地步。
推薦使用源代碼格式化工具而不是 ESLint 來對代碼進行格式化。源代碼格式化程序旨在理解整個文件并在整個文件中應用一致的格式。推薦以下兩個格式化工具：
如果不想用專門的格式化工具，可以使用 @stylistic/eslint-plugin-js（針對JavaScript）或 @stylistic/eslint-plugin-ts（針對TypeScript）。這些包分別包含ESLint核心和 typescript-eslint 中的被棄用的格式化規則，這些規則會繼續維護。
以下列表包含 v8.53.0 中將棄用的所有規則：
這些規則將在下一個版本中被棄用，但在至少 ESLint v10.0.0 之前不會被移除。仍然可以使用它們，但在 ESLint CLI 中可能會看到看用警告。
參考：https://eslint.org/blog/2023/10/deprecating-formatting-rules/
本文鏈接：http://www.tebozhan.com/showinfo-26-16028-0.htmlESlint 終于把這個大麻煩解決了！
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： Go的異步編程：使用Futures與Promises
下一篇： REST API設計模式和反模式
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號