NPM项目的每个git分支是否都有不同的node_modules依赖项？

Question

我假设在开发NPM项目时，每个git分支（或您使用的任何版本控制系统）可能指向文件系统上的一组不同的node_modules 。 真的吗？ 这是如何运作的？ 它是否会对磁盘空间等造成任何问题？

或者，因为node_modules最常见.gitignore'd ，那么node_modules文件在Git分支之间共享？ 再一次，它会如何/有效？

*请注意，Node.js / NPM与其他平台/语言根本不同，因为依赖关系通常存储在本地，而不是存储在计算机的某个中心位置。

Answer 1

按照惯例， 不应添加任何可以从外部源生成或引入的文件，库或二进制文件。 这包括node_modules ; 因为一旦你进行了npm install就可以随时使用*，没有理由或激励**想要将它放入源代码控制中。 在最坏的情况下，它也会膨胀你的存储库，用你根本无法控制但不一定要查看的东西填充你的差异。

我不希望NPM项目的不同Git分支包含不同的node_modules文件夹。 我只期望一个node_modules文件夹，如果一个分支让我适应依赖关系，我会寻找重新安装依赖项（并注意它以确保其他东西没有出错）。

作为附录， .gitignore中的任何文件或文件夹都不会被Git索引或跟踪。 如果这些文件或文件夹的内容发生变化，Git就更聪明了。 这也意味着，当在分支之间切换时， .gitignore中的文件或文件夹的内容保持不变。

^{*：如果你使用的库没有被突然猛拉。 或者存储库不受巨大的DDoS的影响。}

^{**：鉴于某些NPM软件包今年的可靠性不是100％，这可能有一些动力，但这是团队和架构驱动的决策，我怀疑将其置于源代码管理中是最大的处理它的理想和方便的方法。}

Answer 2

有两种思想流派，都有其优点。

1）永远不要检查node_modules并在deploy / install上重建

该方法在很大程度上依赖于NPM和部署环境的连接性。 每次运行部署时都会下载并安装（和/或编译） node_modules 。

积极因素：您的存储库要小得多。

NPM模块安装在它们将运行的环境中。

关注：与第三方联系的消息来源 - 去看看整个left-pad东西。 如果无法下载一个依赖项，那么整个构建系统都会挂起来干。 “Cranky and Paranoid old timers”会将此作为检查所有内容的理由（或在某处运行您自己的私有NPM）。

分支管理 - 就像您在问题中提到的那样，某些分支可能没有相同的依赖关系。 Dev1添加了新功能并使用了新的包。 现在Dev2运行dev分支或其他什么，一切都坏了，他们需要知道npm install新包。 更简单的是npm软件包的版本更改（现在你需要npm update因为npm install会说没有任何改变），或者他们的node_modules升级为“新功能10”，但他们需要清除所有内容“降级”以修复“之前的错误43”。 如果您正在积极开发超过2-3的团队，请留意这一点。

构建时间 - 如果需要考虑，下载和安装所有内容需要更长的时间。 或长了不少 。

2）始终检查所有可能的内容

此方法包括node_modules作为repo的一部分。

积极因素：不依赖于第三方来源。 你有你需要运行的东西。 你的代码可以永久存在，如果npm关闭或者repo被删除也没关系。

分支是独立的，因此Dev2切换到该分支时会自动包含Dev1的新功能

部署时间较短，因为不需要安装太多。

担心：存储库要大得多。 代码克隆需要更长的时间，因为有更多的文件。

Pull Requests需要额外的照顾。 如果一个软件包与核心代码一起更新（或安装），那么PR就是一团糟，有时难以理解。 “500个文件已更改”，但实际上您更新了一个包并更改了两行核心代码。 它可以帮助分解为两个PR - 一个是混乱（包更新）和一个实际可审查（核心代码更改）。 再次，为这一个做好准备。 这些软件包不会经常更改，但是代码审查需要更长时间（或者更加小心）。

操作系统依赖包可能会中断。 基本上，使用gyp安装/编译的任何东西都可以依赖于操作系统（以及其他）。 大多数软件包都是“纯JS”，只是脚本，无处不在。 想象一下，当您部署到Linux时，所有开发人员都在OSX上运行和测试，您无法检查在MAC上编译的那些包，因为它们不能在Linux上运行。 一个奇怪的解决方法是将大多数软件包定义为“dev dependencies”（ - --save-dev ）和需要编译为正常的软件包（“production”， - --save ），然后运行npm install --production以便dev依赖项未安装（并且已经存在），但其他依赖项是。

结论

这取决于。 （你不是一直讨厌听到这个吗？:)

根据您的团队和您的顾虑，您可能采取任何一种方法。 两者都有其优点，您将决定哪种更有益于您。 两者都有缺点，所以在你得到之前要注意这些！

Answer 3

具有不同节点模块集的两个分支处于这样的情况：一个分支处于开发阶段而另一个分支处于生产分支。 在这种情况下，开发分支将拥有比生产更多的节点模块。 如果我没有错，任何其他情况都可能让你遇到麻烦。

将node_modules推送到远程版本控制存储库是不好的做法，因此每当克隆分支或拉动代码以下载添加到package.json的任何新节点模块时，只需依赖npm install 。

Answer 4

我个人忽略.node_modules但我在不同的分支中有不同的package.json，当我切换时我重新安装依赖项

Answer 5

显然，由于您的实际存储库中没有node_modules，因此需要再次安装节点模块，并且每个分支可能都有自己的要求，因为您可能会更新具有新依赖关系的server.js，并且还需要确保在生产服务器中也有这些新添加的节点依赖项。