【问题标题】：Advantages of bundledDependencies over normal dependencies in npmbundledDependencies 相对于 npm 中的普通依赖项的优势
【发布时间】：2012-06-27 18:56:02
【问题描述】：

npm 允许我们指定bundledDependencies，但是这样做有什么好处呢？我想如果我们想确保我们得到正确的版本，即使我们引用的模块被删除，或者捆绑可能有速度优势？

有人知道bundledDependencies 相对于普通依赖的优势吗？

【问题讨论】：

'如果这拼写为“bundleDependencies”，那么这也是光荣的。很棒的文档！
然而，不知何故，将其修复为仅显示“也很荣幸”让人感到难过。在紧要关头，如果我命令武士或骑士寻求帮助，我绝对希望他配备兼容的武器和盔甲 - 并且是光荣的。
“我想如果我们想绝对确保我们得到正确的版本，即使我们引用的模块被删除”突然变得很重要：blog.npmjs.org/post/141577284765/kik-left-pad-and-npm
另见stackoverflow.com/questions/11459475/…。

标签： node.js npm dependencies

【解决方案1】：

Node 目前最大的问题之一是它的变化速度有多快。这意味着生产系统可能非常脆弱，npm update 很容易破坏。

使用 bundledDependencies 是解决此问题的一种方法，它可以确保，正如您正确推测的那样，无论其他情况发生什么变化，您都将始终提供正确的依赖项。

您还可以使用它来捆绑您自己的私有捆绑包并随安装一起交付。

【讨论】：

它如何始终提供正确的依赖关系？这是否意味着npm update 不会影响 bundledDependencies 中的任何依赖项？
是的，正确的。请注意，捆绑的依赖项可能在任何基本方面都不“正确”。它们正是捆绑 SAID 的人是正确的。
可能是因为您正在查看一个 五岁半 的答案！ Node.JS 在那段时间的进步是惊人的。也许您想添加一些有用的东西作为评论？

【解决方案2】：

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

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

【讨论】：

【解决方案3】：

对于快速阅读者：这个 QA 是关于 package.json bundledDependencies 字段，不是关于 package。

bundledDependencies 做了什么

“bundledDependencies”正是它们的名字所暗示的。应该在您的项目中的依赖项。所以功能和普通依赖基本一样。运行npm pack时也会打包。

何时使用它们

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

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

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

当不使用捆绑依赖时

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

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

选项 1：使用节点 8 附带的较新的 NPM 版本 5。它使用 package-lock.json 文件（请参阅 node blog 和节点 8 版本）
选项 2： 使用 yarn 而不是 npm。它是来自 facebook 的包管理器，比 npm 更快，它使用 yarn.lock 文件。否则它使用相同的package.json。

这与其他包管理器（如 Bundler）中的锁定文件相当或货物。它类似于 npm 的 npm-shrinkwrap.json，但不是有损，它会产生可重现的结果。

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

选项3：这是之前推荐的方法，我不再推荐了。这个想法是大部分时间使用npm shrinkwrap，有时将整个东西，包括 node_module 文件夹，放入你的代码存储库。或者可能使用shrinkpack。 node.js blog 和 joyent developer 网站上讨论了当时的最佳做法。

另见

这有点超出了问题的范围，但我想提一下最后一种依赖关系（我知道的）：peer dependencies。另请参阅此 related SO question 以及 bundledDependencies 上的 yarn 的文档。

【讨论】：

“包括 node_module 文件夹”——这是一件很奇怪的事情，它会用生成的代码污染你的仓库......尤其是当你使用原生模块时......
@Olexandr 在这和冒险包破坏你的应用程序之间，我想选择很容易。请注意，您可以放入一个单独的分支（例如，如果使用 git）。同意，这远非理想的解决方案。
我建议不要签入 node_modules，因为例如像 phantomjs 这样的软件包会为当前系统安装适当的二进制文件。这意味着，如果一个开发人员在 Linux 上运行 npm install 并签入 node_modules ——它将不适用于在 Windows 上克隆存储库的另一个开发人员。最好检查 npm install 下载的 tarball 并将 npm-shrinkwrap.json 指向它们。您可以使用npm install -g shrinkpack 工具自动执行此过程。
感谢@nha，您也可以使用 shrinkpack 来保护您，因为注册表 tarball 会在您的项目存储库中。
@fold_left 确实是的，感谢您指出它（以及制作收缩包）。我只是说，如果 npm 注册表像一个不可变的数据存储一样，所有这些都可以避免。

【解决方案4】：

在操作上，我将 bundledDependencies 视为模块的私有模块存储，其中依赖项更加公开，在您的模块及其依赖项（和子依赖项）之间解决。您的模块可能依赖于旧版本，例如 react，但依赖项需要最新和最好的。您的包/安装将在node_modules/$yourmodule/node_modules/react 中生成您的固定版本，而您的依赖项将在node_modules/react 中获取它们的版本（如果他们愿意，则为node_modules/$dependency/node_modules/react）。

警告：我最近遇到了一个依赖项，它没有正确配置其对 react 的依赖项，并且在 bundledDependencies 中做出反应导致该依赖模块在运行时失败。

【讨论】：

【解决方案5】：

我很惊讶我在这里还没有看到这个，但是当仔细选择时，bundledDependencies 可用于从npm pack 生成一个可分发包，该包将在未配置npm 的系统上运行。如果您有例如，这将很有帮助。未联网/未联网的系统：将您的包放在拇指驱动器（或其他任何东西）上并解压缩 tarball，然后 npm run 或 node index.js 就可以了。

也许有更好的方法来捆绑您的应用程序以“离线”运行，但如果有的话，我还没有找到。

【讨论】：