在 Heroku 上创建 Node.js 应用程序时，我应该将文件夹“node_modules”签入 Git 吗？

第二次更新

常见问题解答不再可用。

从 shrinkwrap 的文档中：

如果您希望锁定包中包含的特定字节，例如对能够重现部署或构建有 100% 的信心，那么您应该将您的依赖项检查到源代码控制中，或者采用其他一些可以验证的机制内容而不是版本。

香农和史蒂文之前提到过这一点，但我认为这应该是公认答案的一部分。

更新

以下建议 has been updated 列出的来源。他们不再建议提交 node_modules 文件夹。

通常，没有。允许 npm 为您的包解析依赖项。对于您部署的包，例如网站和应用程序，您应该使用 npm shrinkwrap 锁定您的完整依赖关系树：https://docs.npmjs.com/cli/shrinkwrap

原帖

作为参考，npm FAQ 清楚地回答了您的问题：

将 node_modules 检入 git 以获取您部署的内容，例如网站和应用程序。不要将 node_modules 签入 git 以获取打算重用的库和模块。使用 npm 管理开发环境中的依赖项，而不是部署脚本中的依赖项。

要了解这方面的一些充分理由，请阅读 Mikeal Rogers' post on this。

来源：https://docs.npmjs.com/misc/faq#should-i-check-my-node-modules-folder-into-git

---

对于不将文件夹 node_modules 检入 Git，我最大的担忧是 10 年后，当您的生产应用程序仍在使用时，npm 可能不会出现。或者 npm 可能会损坏；或者维护人员可能决定从他们的存储库中删除您依赖的库；或者您使用的版本可能会被删减。

这可以通过 Maven 等存储库管理器来缓解，因为您始终可以使用自己的本地 Nexus (Sonatype) 或 Artifactory 来维护您使用的软件包的镜像。据我了解，npm 不存在这样的系统。对于像 Bower 和 Jam.js 这样的客户端库管理器也是如此。

如果您已将文件提交到自己的 Git 存储库，那么您可以随时更新它们，并且您可以舒适地进行可重复构建，并且知道您的应用程序不会因为某些第三方操作而中断。

---

您不应该在 .gitignore 文件中包含文件夹 node_modules（或者更确切地说you should include folder node_modules in your source部署到 Heroku）。

如果文件夹 node_modules：

如果存在，则 npm install 将使用那些供应商的库，并将使用 npm rebuild 重建任何二进制依赖项。

不存在，那么 npm install 将不得不自己获取所有依赖项，这会增加 slug 编译步骤的时间。

请参阅 these exact steps 的 Node.js buildpack 源代码。

但是，最初的错误看起来是 npm 和 Node.js 版本之间的不兼容。最好始终根据 this guide 明确设置 packages.json 文件的 engines 部分，以避免这些类型的情况：

{
  "name": "myapp",
  "version": "0.0.1",
  "engines": {
    "node": "0.8.x",
    "npm":  "1.1.x"
  }
}

这将确保development/production parity并减少将来出现此类情况的可能性。

---

发表此评论后，我打算离开：Should I check in folder "node_modules" to Git when creating a Node.js app on Heroku?

但是 Stack Overflow 的格式很奇怪。

如果您没有相同的机器并且正在检查 node_modules，请在本机扩展上执行 .gitignore。我们的 .gitignore 看起来像：

# Ignore native extensions in the node_modules folder (things changed by npm rebuild)
node_modules/**/*.node
node_modules/**/*.o
node_modules/**/*.a
node_modules/**/*.mk
node_modules/**/*.gypi
node_modules/**/*.target
node_modules/**/.deps/
node_modules/**/build/Makefile
node_modules/**/**/build/Makefile

通过首先检查所有内容进行测试，然后让另一个开发人员执行以下操作：

rm -rf node_modules
git checkout -- node_modules
npm rebuild
git status

确保没有文件更改。

---

我认为 npm install 不应该在生产环境中运行。有几件事可能出错 - npm 中断、下载较新的依赖项（shrinkwrap 似乎已经解决了这个问题）是其中两个。

另一方面，不应将文件夹 node_modules 提交给 Git。除了它们的大尺寸之外，包括它们在内的提交可能会分散注意力。

最好的解决方案是：npm install 应该在类似于生产环境的 CI 环境中运行。所有测试都将运行，并且将创建一个包含所有依赖项的压缩发布文件。

---

我一直在使用提交 node_modules 文件夹和收缩包装。两种解决方案都没有让我高兴。

简而言之：一个提交的 node_modules 文件夹给存储库增加了太多的噪音。而且 shrinkwrap.json 不容易管理，并且不能保证一些收缩包装的项目将在几年内构建。

我发现 Mozilla 正在为他们的一个项目使用单独的存储库：https://github.com/mozilla-b2g/gaia-node-modules

所以我很快就在 Node.js CLI 工具中实现了这个想法：https://github.com/bestander/npm-git-lock

在每次构建之前，添加：

npm-git-lock --repo [git@bitbucket.org:your/dedicated/node_modules/git/repository.git]

它将计算您的 package.json 文件的哈希值，并将从远程存储库中检出文件夹 node_modules 内容，或者，如果它是此 package.json 文件，将执行干净的 npm install 并将结果推送到远程存储库。

---

将 npm 版本显式添加到文件 package.json ("npm": "1.1.x") 并且不将文件夹 node_modules 签入 Git 对我有用。

部署可能会更慢（因为它每次都下载包），但我无法在签入时编译包。Heroku 正在寻找只存在于我的本地机器上的文件。

---

不要签入文件夹 node_modules，而是为您的应用程序创建一个 package.json 文件。

package.json 文件指定应用程序的依赖项。 Heroku 然后可以告诉 npm 安装所有这些依赖项。您链接到的教程包含有关 package.json 文件的部分。

---

来自 "node_modules" in Git：

回顾一下。仅为您部署的应用程序签入 node_modules，而不是您维护的可重用包。任何编译的依赖项都应该签入它们的源，而不是编译目标，并且应该在部署时 $ npm rebuild。

我最喜欢的部分：

所有在你的 gitignore 中添加 node_modules 的人，去掉那个狗屎，今天，它是一个时代的产物，我们都乐于把它抛在后面。全局模块的时代已经结束。

_{（原来的链接是 this one，但现在已失效。感谢@Flavio 指出。）*}

---

我正在使用这个解决方案：

创建一个包含文件夹 node_modules 的单独存储库。如果您有应为特定平台构建的本机模块，则为每个平台创建一个单独的存储库。使用 git submodule 将这些存储库附加到您的项目存储库： git submodule add .../your_project_node_modules_windows.git node_modules_windows git submodule add .../your_project_node_modules_linux_x86_64 node_modules_linux_x86_64 创建从特定于平台的 node_modules 到 node_modules 目录的链接，并将 node_modules 添加到 .gitignore。运行 npm 安装。提交子模块存储库更改。提交您的项目存储库更改。

因此，您可以在不同平台上的 node_modules 之间轻松切换（例如，如果您在 OS X 上开发并部署到 Linux）。

---

场景一：

一种情况：

您使用从 npm 中删除的包。如果您在 node_modules 文件夹中拥有所有模块，那么这对您来说不是问题。如果你在 package.json 中只有包名，你就不能再得到它了。

如果一个包的使用时间少于 24 小时，您可以轻松地将其从 npm 中删除。如果它超过 24 小时，那么您需要联系他们。

但：

如果您联系支持人员，他们将检查删除该版本的软件包是否会破坏任何其他安装。如果是这样，我们不会删除它。

read more

所以这种情况的可能性很低，但有第二种情况......

场景二：

这种情况的另一种情况：

你开发一个企业版的软件或一个非常重要的软件，并在你的 package.json 中写：

"dependencies": {
    "studpid-package": "~1.0.1"
}

您使用该软件包的function1(x)方法。

现在 studpid-package 的开发人员将方法 function1(x) 重命名为 function2(x) 并且他们犯了一个错误......他们将包的版本从 1.0.1 更改为 1.1.0。这是一个问题，因为当您下次调用 npm install 时，您将接受版本 1.1.0，因为您使用了波浪号 ("studpid-package": "~1.0.1")。

现在调用 function1(x) 可能会导致错误和问题。

将整个 node_modules 文件夹（通常超过 100 MB）推送到您的存储库，将占用您的内存空间。与数百 MB（package.json 和 node_modules）相比，只有几 kb（仅 package.json）……想想看。

如果出现以下情况，您可以这样做/应该考虑一下：

软件非常重要。

当某些事情失败时，它会花费你的钱。

你不信任 npm 注册表。 npm 是集中式的，理论上可以关闭。

在 99.9% 的情况下，您不需要发布 node_modules 文件夹，如果：

您只为自己开发软件。

你已经编写了一些程序，只是想在 GitHub 上发布结果，因为其他人可能会对它感兴趣。

如果您不希望 node_modules 出现在您的存储库中，只需创建一个 .gitignore 文件并添加行 node_modules。

---

如果您正在滚动您自己的特定于您的应用程序的模块，您可以：

将这些（并且只有那些）保留在应用程序的 /node_modules 文件夹中，并将所有其他依赖项移出到父 ../node_modules 文件夹。这将起作用，因为 NodeJS CommonJS 模块系统如何通过向上移动到父目录等方式工作，直到到达树的根目录。见：https://nodejs.org/api/modules.html

或者 gitignore 所有 /node_modules/* 除了你的 /node_modules/your-modules。请参阅：使 .gitignore 忽略除少数文件之外的所有内容

这个用例非常棒。它使您可以很好地保留您专门为您的应用程序创建的模块，并且不会与可以稍后安装的依赖项混淆。

---