清理并加速 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中文网其他相关文章！