问npm安装许多依赖项。

EN

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

V8引擎、节点模块(依赖项)和V8(对它们进行)

Node.JS是建立在V8引擎上的，它的源代码是C++。这意味着Node.js的依赖关系基本上是用C++编写的。

现在，当您使用require作为依赖项时，您将从c++程序或js库中取出代码/函数。这就是如何建立库/依赖关系的方法。

库有如此多的函数，因此您将不使用

例如，看看快速验证器模块。它在那里有很多功能。当您需要模块时，您是否使用它提供的所有功能？答案是no。人们需要这样的包只是为了使用它的一个好处，所有的功能最终都会被下载，这就占用了不必要的空间。

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

示例: Javascript是用C/C++语言编写的，这些语言是用汇编编写的。把它想象成一棵树。您每次都创建新的分支，以便更方便地使用，最重要的是节省时间。它能让事情变得更快。这是创建新依赖项的类似情况，当人们使用已经存在的依赖项(require)创建新的依赖项时，而不是编写完整的C++程序或JS脚本，因为这使一切变得更容易。

当需要其他NPMs来创建新的时，就会出现问题。

当依赖关系的作者需要其他依赖项来使用它们的一些(少量)好处时，他们最终会下载所有这些依赖项(他们并不真正关心这些依赖项，因为他们大多数不担心大小，或者他们宁愿这样做，也不愿意显式地编写新的依赖项或C++插件)，这需要额外的空间。例如，您可以看到表达式验证器模块使用从这个链接。的依赖关系。

因此，当您有使用大量依赖项的大型项目时，您最终会占用它们太多的空间。

解决此的方法

编号1

这需要一些Node.JS专家。为了减少下载包的数量，专业的Node.JS开发人员可以转到模块保存的目录中，打开javascript文件，查看它们的源代码，并删除它们在不改变包结构的情况下不会使用的功能。

2号(很可能不值得你花时间)

您还可以创建用C++或更好的JS编写的个人依赖关系，这实际上会占用尽可能少的空间(取决于程序员)，但减少一些大小而不是做工作需要花费最耗时、效率最低的时间。(注意:大多数依赖项都是用JS编写的)

编号3(公共)

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

结论与注记

所以从根本上说，下载所有的节点包是不可能的，但是如果你相信你能做到的话，你可以使用解决方案1，这也有可能破坏依赖的整个意图。(因此，让它个人化，并用于特定的目的)，或者仅仅使用像WebPack这样的模块。

另外，问自己这个问题，这些包裹真的会给你带来麻烦吗？

不，在您的项目中添加大约900个包依赖项是没有意义的，仅仅因为您想添加一些模板。但这取决于你！

模板的沉重不是对node.js生态系统的挑战，也不是对他的主要软件包系统npm的挑战。

事实上，javascript社区往往使最小的模块负责一项任务，而只负责一项任务。我想这不是件坏事。但它可能会导致项目中存在大量依赖项的情况。

如今，硬盘内存很便宜，没有人再关心如何开发高效/小型应用程序了。

和往常一样，这只是一个选择的问题。

为几个kB项目交付数百个重达数百MB的包有什么意义？

没有..。

如果您打算将其提供给其他开发人员，只需使用gitignore (或从共享包中删除) node_modules或bower_components目录即可。开发人员只需根据需要再次安装依赖项;)

如果它像HTML模板或类似的东西一样简单，节点很可能只是为了让您作为开发人员的生活更容易提供实时重新加载、编译/转换类型记录/babel/SCSS/SASS/LESS/Coffee.(清单继续;P )等

在这种情况下，依赖关系很可能只是dev_dependencies，而在生产环境中根本不需要) ;)

此外，许多包都有独立的生产和开发依赖项，因此您只需要安装产品依赖项.

npm install --only=prod

如果您的项目在生产中确实需要很多项目，而且您真的想避免这种情况，只需花费一些时间并包含您的项目所需的css/js文件(这可能是一项艰巨的任务)。

更新

生产与默认安装

大多数项目都有不同的开发和生产依赖性，

开发依赖项可能包括诸如SASS、类型记录等编译器、uglifier(小型化)、可能是像实时重新加载之类的东西。

其中，作为生产版本，将不会有那些缩小大小的node_modules目录。

**无node_modules**

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

无法访问node_modules的

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