npm安装许多依赖项
我最近买了一个HTML模板，里面包含了很多插件，放在bower_components目录里面，还有一个package.js文件。 我想安装另一个我喜欢的软件包，但是决定使用npm来达到这个目的。
当我input：
npc install pnotify
包含约900个目录的node_modules已经被创build。
那些是什么？ 为什么他们随我的包一起安装？ 我做了一些调查，结果发现那些是需要的，但是真的，我是否需要在生产中提供我的模板，并且有数百个不必要的软件包？
这是一个很好的问题，我想指出一些事情。
V8引擎，节点模块（依赖）并require它们
Node.JS是build立在V8引擎上的，它的源代码是C ++。 这意味着Node.JS的依赖关系基本上是用C ++编写的。
现在，当你require一个依赖的时候，你实际上从一个c ++程序中脱离了代码/函数。 这就是图书馆/依赖关系。
图书馆有许多function，你不会使用
例如，看看express-validator模块 。 它有那么多的function 当你需要模块时，你是否使用它提供的所有function？ 答案是否定的 。 人们需要这样的软件包只是为了使用它的一个好处，所有的function最终都会被下载，从而占用不必要的空间。
将其他节点依赖关系中的节点依赖关系视为解释语言
例如：JavaScript是用C / C ++语言编写的，这些语言是用Assembly编写的。 把它想象成一棵树。 您每次创build新的分支机构以便更方便地使用，最重要的是节省时间 。 它使事情变得更快 。 当创build一个新的依赖关系时，创build新的依赖关系的情况也是如此，当他们使用（ require ）那些已经存在的依赖关系时，而不是编写一个完整的C ++程序。
当需要其他NPM创build一个新的问题时会出现问题
当依赖关系的作者需要其他依赖从这里到那里只是使用他们的一些（less量）好处时，他们最终将他们全部下载（ 他们并不关心，因为他们宁愿这样做，而不是明确的用C ++编写一个新的插件 ），这需要额外的空间。 例如，您可以看到express-validator模块在此链接中使用的依赖关系。
所以，当你有大量的项目，使用大量的依赖项，你最终会占用他们的空间。
方法来解决这个问题
1号
- 这需要Node.JS上的一些专家。 为了减less下载的软件包的数量，一个专业的Node.JS开发人员可以进入保存模块的目录，打开javascript文件，查看它们的源代码，并删除不改变的function，而不改变包的结构。
2号（这几乎是不可能的）
- 你也可以创build自己的用C ++编写的个人依赖关系，从字面上看占用最less的空间，但是花费最多的时间。 我不build议这样做！ 你需要C ++的专家来达到这种目的。
结论&&注意
所以基本上没有下载所有的节点包的情况，但是如果你相信你可以做到这一点，或者让别人来处理，你可以使用解决scheme1。 我仍然认为这不是一个好主意。
另外，自己问这个问题，那些包真的会给你带来问题吗？
不，在您的项目中添加大约900个软件包依赖关系是没有意义的，因为您想添加一些模板。 但这取决于你！
模板的重要性不是挑战node.js生态系统，也不是他的主包系统npm。
事实上，javascript社区倾向于尽可能地将最小的模块负责一个任务，而只有一个。 我想这不是一件坏事。 但是这可能会导致在项目中有很多依赖的情况。
如今的硬盘内存很便宜，没有人关心制作高效/小应用程序。
一如既往，这只是一个select的问题。
为几个kB项目交付几百个MB的软件包有什么意义呢？
没有..
如果您打算将其提供给其他开发人员，只需将gitignore（或从共享程序包中删除） node_modules或bower_components目录中。 开发人员只需根据需要重新安装依赖关系;）
如果它是一个简单的HTML模板或类似的东西，节点将最有可能在那里只是为了使您的生活作为一个开发人员更容易提供生活重新加载，编译/ transpiling typescript / babel / SCSS / SASS / LESS /咖啡… （名单继续; P）等
在这种情况下，依赖性很可能只是dev_dependencies，在生产环境中根本不需要）
还有很多软件包都带有独立的生产和开发依赖项，所以你只需要安装生产依赖项…
npm install --only=prod
如果你的项目在生产中需要很多项目，而且你确实想避免那些东西，那么花点时间，包括你的项目需要的css / js文件（这可能是一项艰巨的任务）。
更新
生产与默认安装
大多数项目具有不同的开发和生产依赖性，
开发依赖可能包括像SASS，打字稿等编译器，uglifiers（缩小），也许像现场重新加载等东西
生产版本不会有那些减小node_modules目录大小的node_modules 。
**没有node_modules **
在某些html模板types的项目中，您可能不需要生产中的任何node_modules ，因此您可以跳过npm install 。
无法访问node_modules
或者在某些情况下，当服务器存在于node_modules本身时，访问它可能被阻塞（因为没有必要从前端访问它们）。
那些是什么？ 为什么他们随我的包一起安装？
存在依赖关系以便通过模块化重用代码。
我是否需要在生产环境中提供我的模板以及数百个不必要的软件包？
一个人不应该这么快地否认这种模块化。 如果您内嵌您的require并消除死代码，您将失去自动应用于您的代码的依赖关系的维护补丁的好处。 你应该看到这是一种编译forms，因为…嗯… 它是汇编 。
尽pipe如此，如果您被许可以这种编译forms重新分配所有的依赖关系，那么您将很高兴得知这些优化是由将JavaScript编译为Javascript的编译器执行的。 Closure编译器 ，作为我偶然发现的第一个例子，似乎执行高级编译 ，这意味着你得到死代码删除和函数内联 …这似乎很有前途！