这是我使用Grunt和Git的第一个项目。在我的项目中，我有通过命令">npm install grunt"创建的"*node_modules*"目录。现在我想将我的项目发布到 GitHub。
我的项目应该包含"node_modules"还是应该省略它？恐怕这会让不熟悉 Grunt 的开发人员感到恐惧。事实上，我很困惑为什么你应该为每个项目单独安装 grunt。为什么无法全局安装？
这是我的安装：grunt-contrib-concat，grunt-contrib-jshint，grunt-contrib-qunit，grunt-contrib-uglify，grunt-contrib-watch。
您不应该全局安装咕噜声和咕噜声插件的原因是，这样您一次只能安装每个版本的 1 个版本。在与团队合作时，这也意味着团队中的每个成员都必须运行相同版本的 grunt 和每个 grunt 插件。
与团队协调这些版本并在跳转到不同项目时切换版本是一场噩梦。解决方案是在本地安装所有内容。它只是文件空间，大多数模块不会占用很多空间。
大多数人不会将他们的node_modules文件夹提交到 github 中。package.json中列出的每个依赖项都可以通过键入以下内容来重新安装：npm install在同一文件夹中。
使用npm install grunt --save-dev在安装插件和模块时保存到package.json。
提交node_modules的唯一合理理由 IMO，是使用旨在部署到生产的私有应用程序和存储库。您希望确保依赖项被锁定并且不会在推送时破坏某些内容的地方。还有其他策略可以避免提交node_modules，即使有这个用例(例如 npm 收缩包装)。
总之：
- 如果您正在部署应用程序并且对锁定部门感到偏执，请提交您的node_modules。
- 其他一切，不要承诺你的node_modules。
@"提交node_modules的唯一合理理由，IMO，是使用 私有应用程序和存储库打算部署到生产环境。
我从不将我的node_modules提交到 repo 中，只在 package.json 中提交更改。但事实证明，对于一个拥有多个开发人员和大量实验性功能分支的项目来说，这是一个非常糟糕的主意。由于node_module文件夹未使用 git 进行版本控制，因此您最终需要在每个分支交换机上运行 npm install，因为模块在不同版本之间可能不同。一场真正的噩梦...
你最终会听到"这个废话不再工作了！！"，只是因为有人更新了功能分支中的节点模块。因此，我现在建议为具有多个开发人员和分支的项目包含node_modules。带走很多痛苦...
编辑：只是想添加一些其他事情，以记住签入/未签入节点模块，我不得不(痛苦地)学习：
- 始终在package.json中锁定您的版本 - 这意味着 基本上删除软件包前面的所有修改器 版本号(如：~，>，*和任何可能的)如果你有 有人运行 npm 安装，您希望他们得到您拥有的 (语义版本控制在理论上是伟大的，但对不起，它是 只是不可靠，你永远不希望更新软件包 在你不知情的情况下)。否则，就眼睁睁地看着世界燃烧掀翻 一遍...
编辑(28.02.2018)：不再需要这样做 - 就像在新版本中一样 npm 和 yarn-package manager 在安装时生成一个 .lock-file - 定义确切的已安装软件包版本 - 可以提交和 由其他开发人员使用。
- 如果在混合操作系统环境中工作，则会出现一些有问题的咕噜声- 应该谨慎签入的软件包，例如grunt-imagemin，这可能会阻碍Windows上的签出，使用msysgit，因为它们的路径很长。对于 Windows 的 git 中的文件名太长
- 我发现最好的做法是将我的工作流自动化和相应的 npm 包放入它自己的子文件夹/存储库中，以实现可重用性和更好的项目维护 - 因为它可以防止自动化模块与实际的 nodejs 应用程序包混合。