node_modules 问题

我想我甚至不是第一个在 dev.to 上讨论这个问题的人。我快速搜索了一下，试图找到任何解决方案，最终都以本文开头的图片作为结论。node_modules文件夹是项目依赖项的存储位置，这是众所周知的。它的权重也是众所周知的。

为什么我决定现在发泄我的沮丧

黑色星期五来了！这意味着折扣和更新电脑的机会。因此，我决定买一块固态硬盘 (SSD) 来提升我的笔记本电脑性能，从 1TB 的 HDD 升级到 500GB。我现在所有文件加起来有 299GB，所以不会损失太多空间，但即便如此，我还是决定做一些日常工作，包括备份我的项目。我做的项目不会全部放在 GitHub 上，有时我只是在尝试，不值得费心，但无论如何我都会保留它们。

当我开始复制和粘贴过程时，我记得node_modules有多重......

一些比较

一个清楚显示问题的示例是我的ToRead CLI 项目的node_modules文件夹，如下图所示。

文件夹的大小其实不是问题（虽然我稍后会讲到），但问题在于15000个文件和超过1800个文件夹！？你在开玩笑吧？！这只是一个简单的CLI项目，只有5个文件！为了比较，我们来看看Windows文件夹中有多少个文件和文件夹：

系统统计的时候，我真心觉得node_modules会赢，结果却不是。反正这个文件夹里的文件数量几乎相当于整个操作系统的一半！

正如我之前所说，将node_modules文件夹从一个地方复制到另一个地方时，问题不在于大小，而在于文件和文件夹的数量，以及树的复杂性。这对硬盘来说简直是一场噩梦。查找所有文件需要花费很长时间，更不用说复制它们了。最终，这也会影响npm 的性能，这方面也有一些梗。

其他比较源于我对无服务器的热爱。我经常用 Java 和 JavaScript 实现同一个函数，由于需要将函数与其依赖项捆绑在一起，因此比较哪种语言在依赖管理方面更高效是一个好方法。在我的一个项目中，我用两种语言编写了几乎功能相同的函数，Java 包大小为 11.1 MB，而 NodeJS 包大小为 29.0 MB。因此，NodeJS 在依赖项大小方面也能做得更好。

其他语言

除了 NodeJS，我还用另外两种语言处理依赖关系：Java 和 C#。在我看来，它们处理依赖关系的方式非常相似，而且比 NodeJS 高效得多。

Java 中有 Maven、Gradle 和其他依赖管理应用程序，它们的工作原理基本相同。依赖项有一个远程仓库，通常是 Maven Central，还有一个本地仓库。Maven 总是先在本地仓库中查找依赖项，如果找不到，则从远程仓库下载。依赖项并不像node_modules文件夹那样位于项目内部，而是更具全局性，只需下载一次即可供多个项目使用，只需将其添加到 pom.xml 即可。

C# 也遵循同样的思路，你需要在 .csproj 文件中列出依赖项，然后 Nuget 会通过远程和本地仓库来处理这些依赖项。这种方式处理依赖项效率更高，只需下载一次即可在本地任何项目中使用。

我认为文化差异、语言的构建方式以及人们对库的理解也存在差异。Java 拥有非常成熟的核心库，几乎可以处理所有情况，无论是否常见。因此，Java 中的库通常旨在抽象 Java 已有的功能，使其更易于使用。因此，这些库的依赖关系树更浅，可以更快地访问 Java 核心库。

另一方面，我在 NodeJS 中看到的却恰恰相反，一切都可以成为一个库，甚至是一个将两个数字相加的库（我希望是一个假设的例子），并且库彼此严重依赖，从而生成深度依赖树、许多文件和文件夹。

结论与讨论

我当然没有资格批评 Node.js 的结构和工程，但作为一名用户，我清楚地看到了一个问题，也从其他语言中吸取了一些经验教训，可以用来改进依赖管理，而依赖管理在当今几乎对每个应用程序都至关重要。您认为这个问题是如何产生的？又采取了哪些措施来解决这个问题？如果能听听更有经验的开发者是如何解决这个问题的，那将会非常有趣。