捆绑的依赖优于NPM中的正常依赖
npm允许我们指定捆绑的依赖，但是这样做的优点是什么？ 我想，如果我们想要确保我们能够得到正确的版本，即使我们引用的模块被删除，或者捆绑速度有所提高？
任何人都知道捆绑的依赖优于正常的依赖关系？
为方便起见，在此提取bundledDependencies定义：
bundledDependencies
发布软件包时将捆绑的软件包名称数组。如果拼写“bundleDependencies”，那么这也是光荣的。
例如
bundledDependencies: ['foo', 'bar']
目前与Node最大的问题之一是它变化的速度有多快。 这意味着生产系统可能非常脆弱，一个npm update很容易破坏事物。
使用bundledDependencies是一种解决这个问题的方法，通过确保正确地猜测，无论别的什么东西可以改变，你总能提供正确的依赖关系。
您也可以使用它来捆绑您自己的私有捆绑包，并在安装时交付它们。
对于快速读者来说 ：这个QA是关于package.json的 bundledDependencies字段， 而不是关于包的 。
捆绑的依赖关系是做什么的
“捆绑依赖”正是他们的名字所暗示的。 应该在你的项目中的依赖关系。 所以function基本上和正常的依赖相同。 运行npm pack时，它们也将被打包。
何时使用它们
正常的依赖关系通常是从npmregistry安装的。 因此，在以下情况下捆绑的依赖关系是有用
- 你想重新使用不是来自npmregistry或修改过的第三方库
- 你想重新使用你自己的项目作为模块
- 你想分发你的模块的一些文件
这样，您不必创build（并维护）您自己的npm存储库，但是可以从npm包中获得相同的好处。
何时不使用捆绑的依赖关系
在开发时，我并不认为重点是防止意外更新。 我们有更好的工具，即代码仓库（git，mercurial，svn …）或现在locking文件。
要固定您的软件包版本，您可以使用：
-
选项1：使用节点8附带的较新的NPM版本5.它使用
package-lock.json文件（请参阅节点博客和节点8版本） -
选项2：使用纱线而不是
npm。 它是一个来自Facebook的包pipe理器，比npm快，它使用了一个yarn.lock文件。 否则使用相同的package.json。
这与Bundler或Cargo等其他软件包pipe理器中的锁文件相当。 这与npm的npm-shrinkwrap.json类似，但是它不是有损的，它会产生可重现的结果。
实际上， npm从yarn复制了这个function。
- 选项3：这是以前推荐的方法，我不推荐。 这个想法是在大多数情况下使用
npm shrinkwrapshrinkwrap，有时候把整个东西，包括node_module文件夹，放到你的代码库中。 或者可能使用收缩包装 。 当时的最佳实践在node.js博客和joyent开发者网站上进行了讨论。
也可以看看
这有点超出问题的范围，但是我想提一下最后一种依赖关系（我知道的）： 对等关系 。 也看到这个相关的SO问题 ，也可能是bundledDependencies上的yarn的文档。
其他的好处是你可以把你的内部依赖关系（应用程序组件）放在那里，然后在你的应用程序中需要它们，就好像它们是独立的模块，而不是混淆你的lib /并将它们发布到npm。
如果/当他们成熟的时候，他们可以作为独立的模块生活，你可以很容易地把它们放在npm上，而不需要修改你的代码。
在操作上，我将bundledDependencies看作模块的私有模块存储，其中依赖性更公开，在模块及其依赖关系（和子依赖关系）之间解决。 你的模块可能依赖于比较老的版本，比如反应，但依赖需要最新和最好的版本。 你的软件包/安装将导致你的固定版本在node_modules/$yourmodule/node_modules/react ，而你的依赖将会在node_modules/react （或者node_modules/$dependency/node_modules/react如果他们这么倾向的话会node_modules/$dependency/node_modules/react ）得到他们的版本。
一个警告：我最近碰到一个依赖项，没有正确地configuration它对依赖性的反应，并在bundledDependencies中作出反应，导致依赖模块在运行时失败。
