清理並加速 JS 生態系統 - 迄今為止的旅程

一段時間以來，我一直在努力提高整個生態系統的效能。通常透過清理老化的依賴關係樹、減少安裝佔用空間以及提高常用依賴關係的 CPU/記憶體效能。

這篇部落格文章只是我簡短地嘗試解釋一些導致 e18e 和生態系統清理的旅程。

關於微型公用事業的思考

微型實用程式是安裝大小以及許多專案的依賴關係樹複雜性的主要貢獻者。

is-number 和 is-nan 等套件就屬於這一類。

重要的是，這些套件中的許多在某些情況下確實有用，但肯定不是在常見用例中。

通常在以下情況下可以更換它們：

• 它們是在等效的本機功能不存在的時代編寫的，但現在已經存在
• 他們所做的超越了消費者的需求

範例：is-number

例如，is-number 決定一個值是數字還是非 NaN 或 +/-Infinity 的類似數字的字串。

在某些專案中，這是重複的驗證，最好將其提取到自己的模組或套件中。

但是，在常見情況下，許多消費者從來不需要 NaN 和 Infinity 驗證，甚至不需要支援類似數字的字串。

這為各種項目帶來了一些可能的改進。我們可以用更簡單的內聯邏輯來取代這些專案中使用的這個套件（例如，在許多現實世界的專案中，我們安全地切換到typeof n === 'number' ，因為這些專案後來假設並依賴實際的值）無論如何，號碼）。

另一個例子：is-regexp

您可以使用instanceof測試某物是否為正規表示式：v instanceof RegExp。

但是，在某些情況下（例如使用虛擬上下文），這將不起作用，因為 RegExp 與 v 起源的類別不同。在這些情況下，我們需要使用這樣的東西：

Object.prototype.toString.call(obj) === '[object RegExp]'

如果您不想內聯此類程式碼，並且需要支援虛擬上下文或類似內容，也許庫是有意義的。

但是，在許多情況下，專案無論如何都不支援虛擬上下文（而且不想）。這為我們提供了再次簡化為簡單實例的機會。

支援較舊的運行時

另一個潛在的改進領域是舊版運行時支援。

相當多非常流行的包都有各種類似polyfill的模組的非常深的依賴樹。這些通常由於以下一個或兩個原因而存在：

• 防止全域命名空間被竄改
• 維持對缺乏此功能的運作時的支援

我們中的許多人不需要這種等級的向後相容性，如果我們可以將其修剪掉，可以獲得巨大的效能提升。

值得注意的是，當然，仍然有一些人確實需要在這些限制下工作。這就是為什麼在這個領域，我們經常提供分叉或替代方案，而不是嘗試更改現有的軟體包（無論如何，現有的軟體包都不會接受此類更改）。

開始改善事情

在看到我的 node_modules 對於最小的項目來說有多大、嵌套有多深之後，我在 2018 年左右開始思考這些特定領域。

我最初的幾次改變嘗試是創建某種 ESLint 插件，它可以檢測這些套件並建議將它們刪除。每隔幾個月，我就會有同樣的想法並再次嘗試，但從未真正達到我想要的目標。

這段時間，我至少為各種大型專案做出了貢獻，以清理和改進我能做的事情（例如，我長期以來貢獻的一個是故事書）。

生態系清理

然後，我創建了生態系統清理，這是一個用於提高整個生態系統可能的性能改進的存儲庫（基本上是一個問題追蹤器）。再說一次，這基本上是我和我自己的個人問題追蹤器在一段時間內的情況，但至少它是公開可見的。

不久之後，我開始看到人們出現在問題中並為上游專案做出貢獻。我很高興看到這一點，因為我花了很多年的時間獨自解決這個問題，並想知道我是否有所作為。看到其他人的加入對我們了解其他人的關心有很大幫助。

模組更換

雖然清理項目過去和現在都非常有用，但我們確實沒有地方可以與社區其他人分享存在的好的替代方案。

為了解決這個問題，我創建了模組替換專案。

這個項目基本上包含一些可能被替換的模組的 JSON 清單及其建議的替代方案。這些目前分為三個等級的「嚴格性」或「固執己見」：本機（可以用本機功能替換的模組）、微實用程式（可以用簡單的內聯程式碼替換的模組）和首選（我們認為的模組）應替換為性能更高的替代品）。

程式碼模組

替換專案的下一步是建立一組程式碼模組，以便我們可以自動替換其中一些模組。

在@passle的推動下，這個專案很快就收到了大量以各種codemods形式的貢獻。

codemod 團隊也做了一些很好的工作，將這些移植到 codemod 平台。將來，我們也希望透過某種 CLI 或自動修復規則來提供它們。

e18e

我覺得我們所有關心這個東西的人找到彼此的轉捩點是 e18e。

Bjorn 在提高 astro 的性能方面做了一些出色的工作，而 Marvin 也一直在撰寫有關加速生態系統的類似文章。最終，我們的道路相遇了，我們在旁邊進行了一些精彩的討論。

我們一小群人一起工作，看看我們是否都在同一頁上，以及是否可以以此為基礎建立一個社區。然後是 e18e！

旨在成為人們協作改善生態系統表現的社區空間，這向我們展示了有多少人關心這些事情。許多人已經加入並貢獻了大量資金。我們幾乎每天都看到整個生態系統的速度加快和規模縮小。

一些感謝

社區發展迅速，需要感謝太多人的貢獻。不過，我要特別感謝這些人，他們幫助使這個社區成為可能：

• @帕塔克
• @antfu7
• @bluwyoo
• @passle_

類似地，那些已經在為相同目標同時致力於專案的人們：

• @asleMammadam 透過tinylibs
• pi0 到 unjs

以上是清理並加速 JS 生態系統 - 迄今為止的旅程的詳細內容。更多資訊請關注PHP中文網其他相關文章！