来自https://web.archive.org/web/20150212165006/http://www.futurealoof.com/posts/nodemodules-in-git.html：

编辑：原始链接是此链接，但现在已失效。感谢@Flavio指出。

回顾一下。

• 仅为已部署的应用程序签入node_modules，而不为您维护的可重用软件包签入。
• 任何已编译的依赖项都应检入其源代码，而不是编译目标，并且$ npm应当在部署时重建。

我最喜欢的部分：

所有将node_modules添加到您的gitignore中的人，请删除该屎，今天，这是一个我们非常乐于抛弃的时代的产物。全局模块的时代已经过去。

对我有用的是将一个npm版本显式添加到package.json（“ npm”：“ 1.1.x”），而不是将node_modules检入git。部署起来可能会比较慢（因为它每次都会下载软件包），但是当签入它们时我无法编译这些软件包。Heroku正在寻找仅存在于我本地机器上的文件。

我正在使用此解决方案：

1. 创建一个单独的存储库node_modules。如果您有应为特定平台构建的本机模块，则为每个平台创建单独的存储库。
2. 使用以下命令将这些存储库附加到您的项目存储库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

3. 创建从特定于平台的目录node_modules到node_modules目录的链接，然后添加node_modules到.gitignore。
4. 运行npm install。
5. 提交子模块存储库更改。
6. 提交项目存储库更改。

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

http://nodejs.org/api/modules.html

[...]节点从当前模块的父目录开始，然后添加/node_modules，并尝试从该位置加载模块。

如果在该目录中找不到它，那么它将移至父目录，依此类推，直到到达树的根目录为止。

如果要滚动应用程序专用的模块，则可以将这些模块（并且仅保留那些模块）保留在应用程序的中/node_modules。并将所有其他依赖项移至父目录。

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

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

The package.json file specifies the dependencies of your application. Heroku can then tell npm to install all of those dependencies. The tutorial you linked to contains a section on package.json files.

第二次更新

常见问题解答不再可用。

从以下文档中shrinkwrap：

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

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

更新资料

以下建议列出的来源已更新。他们不再建议node_modules提交文件夹。

通常不会 允许npm解决您软件包的依赖关系。

对于您部署的软件包，例如网站和应用程序，应使用npmrinkwrap锁定完整的依赖树：

https://docs.npmjs.com/cli/shrinkwrap

原始帖子

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

将node_modules检入git中以查找您部署的内容，例如网站和应用程序。不要将node_modules检入git中以查找要重用的库和模块。使用npm来管理开发环境中的依赖关系，而不要在部署脚本中。

并出于一些合理的理由，请阅读Mikeal Rogers对此的帖子。

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

你应该不包括 node_modules在.gitignore（或者说你应该包括 node_modules在源部署到Heroku的）。

如果node_modules：

• 存在，然后npm install将使用这些供应的库，并使用重建任何二进制依赖项npm rebuild。
• 不存在，则npm install必须自己获取所有依赖项，这会增加时间来进行编译。

有关这些确切步骤，请参见Node.js buildpack源。

但是，原始错误似乎是npm和的版本之间不兼容node。始终根据此指南明确设置engines您的部分是一个好主意，以避免出现以下类型的情况：packages.json

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

这将确保开发人员/产品的价格均等，并减少将来发生这种情况的可能性。

我将在此评论后留下此内容：在Heroku上创建node.js应用程序时是否应该将node_modules检入git中？

但是stackoverflow格式化它很奇怪。如果您没有相同的计算机，并且正在检入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

确保没有文件更改。

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

简而言之：提交的node_modules给存储库增加了太多的噪音。
而且shrinkwrap.json并不易于管理，并且不能保证某些收缩包装的项目会在几年内建成。

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

因此，很快我就可以在节点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并将结果推送到远程仓库中。

我不检查node_modulesgit时最担心的是，在未来10年内，当您的生产应用程序仍在使用时，npm可能就不在了。否则npm可能会损坏；或维护者可能决定从其存储库中删除您依赖的库；或者 否则您使用的版本可能会被剪裁掉。

可以使用诸如Maven之类的回购管理器来减轻这种情况，因为您始终可以使用自己的本地Nexus或Artifactory来维护使用的软件包的镜像。据我了解，npm不存在这样的系统。像Bower和Jamjs这样的客户端库管理器也是如此。

如果您已将文件提交到自己的git仓库中，则可以根据需要更新它们，并且可以轻松地进行可重复的构建，并且知道应用程序不会由于某些第三方操作而中断。

我认为npm install不应在生产环境中运行。有几处可能出错的地方-npm中断，下载较新的依赖项（shrinkwrap似乎解决了此问题）就是其中两个。

另一方面，node_modules不应在git上提交。除了它们的大小外，包括它们在内的提交可能会分散注意力。

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