npm允许我们指定bundledDependencies，但是这样做有什么好处？我猜想是否即使删除引用的模块也要绝对确保获得正确的版本，或者捆绑有速度优势？

有人知道bundledDependencies超过普通依赖项的好处吗？

目前，Node最大的问题之一是它的变化速度如何。这意味着生产系统可能非常脆弱，并且npm update很容易损坏东西。

使用bundledDependencies是解决此问题的一种方法，可以确保在正确推测的情况下始终提供正确的依赖关系，而不管其他可能发生的变化。

您还可以使用它捆绑您自己的私有捆绑包，并随安装一起提供。

对于快速读者：此质量检查与package.json bundledDependencies字段有关，而不与package有关。

bundledDependencies可以做什么

“ bundledDependencies”正是其名称所暗示的含义。项目内部应具有的依赖关系。因此，功能基本上与常规依赖项相同。它们在运行时也会被打包npm pack。

何时使用它们

正常依赖关系通常是从npm注册表中安装的。因此，捆绑的依赖项在以下情况下很有用：

• 您想重用不是来自npm注册表或已修改的第三方库
• 您想将自己的项目作为模块重用
• 您想与模块一起分发一些文件

这样，您不必创建（和维护）自己的npm存储库，但可以获得与npm包相同的收益。

何时不使用捆绑的依赖项

但是，在开发时，我认为重点不是要防止意外更新。为此，我们有更好的工具，即代码存储库（git，mercurial，svn ...）或现在锁定文件。

要固定您的软件包版本，可以使用：

• 选项1：使用节点8随附的更新的NPM版本5。它使用package-lock.json文件（请参阅节点博客和节点8版本）。

• 选项2：使用yarn代替npm。它是来自facebook的软件包管理器，比npm使用yarn.lock文件更快速。package.json否则使用相同的方法。

这与其他软件包管理器（如Bundler或Cargo）中的锁文件相当。它类似于npm的npm-shrinkwrap.json，但是它不是有损的，并且可以产生可重复的结果。

npm实际上是从中复制了该功能yarn。

• 选项3：这是以前推荐的方法，我不再推荐了。这个想法是在npm shrinkwrap大多数时间使用，有时将包括node_module文件夹在内的整个内容放入代码存储库中。或者可能使用收缩包装。当时的最佳做法在node.js博客和Joyent开发者网站上进行了讨论。

也可以看看

这有点超出问题的范围，但是我想提一下我所知道的最后一种依赖：对等依赖。另请参阅此相关的SO问题以及yarn关于bundledDependencies的文档。

另一个优点是，您可以将内部依赖项（应用程序组件）放在此处，然后仅在应用程序中要求它们就好像它们是独立模块一样，而不是使您的lib /混乱并发布到npm。

如果/当它们成熟到可以作为单独的模块存在时，您可以轻松地将它们放在npm上，而无需修改代码。

令我感到惊讶的是，我还没有在这里看到它，但是经过精心选择，bundledDependencies它可以用来生成可分发的程序包，npm pack该程序包可以在npm未配置的系统上运行。如果您有一个未联网/不在互联网上的系统，这将很有帮助：将您的包裹放在拇指驱动器（或其他）上，然后打开压缩包的包装，然后npm runornode index.js就可以了。

也许有一种更好的方法来捆绑您的应用程序以使其“离线”运行，但是如果没有，我找不到它。

从操作上讲，我将bundledDependencies视为模块的私有模块存储，其中的依赖关系更加公开，可以在模块及其依赖关系（和子依赖关系）之间解决。您的模块可能依赖于较旧的版本，例如react，但是依赖项需要最新和最新的。您的软件包/安装程序将在中生成您的固定版本node_modules/$yourmodule/node_modules/react，而您的依赖项将在中获取其版本node_modules/react（或node_modules/$dependency/node_modules/react如果他们倾向的话）。

一个警告：我最近遇到了一个依赖关系，该依赖关系未正确配置其对react的依赖关系，而在bundledDependencies中进行反应导致该依赖模块在运行时失败。