这是一个很好的问题，我想指出几点。

V8引擎、节点模块（依赖项）和“需要”它们：

js构建在V8引擎上，V8引擎是用C编写的，这意味着Node.js的依赖项基本上是用C编写的。
现在，当您需要依赖项时，您实际上需要来自C++程序或js库的代码/函数，因为新库/依赖项就是这样创建的。

库有 * 太 * 多的函数，您 * 不会 * 使用

例如，看看express-validator module，它包含了如此多的函数。当你需要这个模块时，你使用了它提供的所有函数吗？答案是不。人们通常需要这样的包只是为了使用它的一个好处，尽管所有的函数最终都被下载了，这占用了不必要的空间。

将从其他节点依赖关系生成的节点依赖关系视为解释语言

例如，JavaScript是用C/C编写的，而其函数和编译器最初是用汇编语言编写的。把它想象成一棵树。为了更方便的使用，最重要的是，为了保存时间，你每次都创建新的分支。它使事情变得更快。类似地，当人们创建新的依赖关系时，他们使用/需要已经存在的依赖关系。而不是重写整个C程序或js脚本，因为这会使一切变得更容易。

要求其他国家预防机制创建新机制时出现问题

当依赖项的作者需要其他依赖项时，可以到处使用一些（少量）从中获益，最终全部下载，（* 他们并不真正关心，因为他们大多数不担心大小，或者他们宁愿这样做，而不是显式地编写一个新的依赖项或C++ addon*），这会占用额外的空间。例如，您可以通过访问this link.来查看express-validator模块使用的依赖项
因此，当您有使用大量依赖项的大型项目时，您最终会为它们占用太多的空间。

解决方法
一号

这需要一些Node.js方面的Maven。为了减少下载包的数量，专业的Node.js开发人员可以转到保存模块的目录，打开javascript文件，查看它们的源代码，并删除他们不会使用的函数，而不改变包的结构。

第二点（很可能不值得您花时间）

你也可以创建用C++编写的 * 你自己的 * 个人依赖项，或者更好的是用js，这实际上会占用尽可能少的空间，这取决于程序员，但是会花费/浪费最多的时间，为了减少大小而不是工作。（**注意：**大多数依赖项都是用js编写的。

编号3（通用）

您可以实现WebPack，而不是使用选项2。

结论和注解

因此，基本上，下载所有节点包是不可能的，但是如果您认为自己可以做到，可以使用解决方案1，这也有可能破坏依赖关系的整个意图（因此，使其个性化，并将其用于特定目的），或者只是使用WebPack之类的模块。
另外，问自己这个问题：那些包裹真的给你带来麻烦了吗？

不，仅仅因为你想添加一些模板，就在你的项目中添加大约900个包依赖项是没有意义的，但是这取决于你！
模板的沉重并没有挑战node.js生态系统，也没有挑战他的主包系统npm。
事实上，javascript社区倾向于使用尽可能小模块来负责一个任务，而且只负责一个。我想这不是一件坏事，但它可能是因为你的项目中有很多依赖项。
现在硬盘内存很便宜，没有人再关心制作高效/小的应用程序了。
一如既往，这只是一个选择的问题。

为一个几KB的项目交付数百个重达数百MB的包有什么意义呢？
没有...
如果你想提供给其他开发者，只需要忽略（或从共享包中删除）node_modules或bower_components目录即可，开发者只需根据需要重新安装依赖项即可;）
如果它是像HTML模板或类似的东西一样简单的东西，那么节点很可能只是为了让你作为一个开发人员的生活更轻松，提供实时重载，编译/翻译 typescript /babel/SCSS/SASS/LESS/Coffee...（列表还在继续;P）等。
在这种情况下，依赖关系很可能只是dev_dependencies，在生产环境中根本不需要;）
也有许多软件包带有独立的生产和开发依赖项，所以你只需要安装生产依赖项...

npm install --only=prod

如果您的项目在生产中确实需要许多项目，并且您确实希望避免这些东西，那么只需花一些时间，将项目所需的css/js文件包含在内（这可能是一项艰巨的任务）。
更新

生产安装与默认安装

大多数项目具有不同的开发和生产依赖关系，
开发依赖可能包括像SASS， typescript 等编译器，丑化器（缩小），也许像活重载等东西。
其中作为生产版本将不会有这些东西减少大小node_modules目录。

没有node_modules

在一些html模板类型的项目中，您可能在生产中不需要任何node_modules，因此您跳过了npm install。

无法访问node_modules

或者在某些情况下，当服务器存在于node_modules本身时，对它的访问可能会被阻止（因为不需要从前端访问这些服务器）。

那些是什么？为什么它们和我的软件包沿着安装？
依赖项的存在是为了通过模块化促进代码重用。
...我是否需要在生产中交付带有数百个不必要的软件包的模板？
人们不应该这么快就放弃这种模块化。如果你内联你的require并消除死代码，你将失去自动应用于你的代码的依赖性的维护补丁的好处。你应该把这看作是一种形式的 * 编译 *，因为......嗯...... * 它是编译 *。
尽管如此，如果您被授权以这种 compiled 形式重新分发所有依赖项，您会很高兴地了解到这些优化是由编译器执行的，该编译器将Javascript编译为Javascript。The Closure Compiler，作为我偶然发现的第一个示例，似乎执行了advanced compilation，这意味着您获得了 * 死代码删除 * 和 * 函数内联 *...这似乎很有前途！

然而，当您需要证明所有npm模块的许可证时，这确实会产生另一个副作用......因此，当您由于依赖关系而拥有数百个npm模块时，这项工作也会变得更加繁琐

很老的问题，但我碰巧遇到了非常类似的情况，正如RA指出。
我尝试使用vscode使用node.js框架，当我尝试使用npm init -y安装startnpm时，它生成了许多不同的依赖项。

• 正在卸载ESlint
• 已重新启动vscode以应用该卸载
• 已删除先前生成的package.json和node-modules文件夹
• 再次执行npm init -y

这解决了我一开始就有这么多依赖项的问题。