NPM项目的每个git分支是否具有不同的node_modules依赖关系?

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

或者,因为node_modules是最常用的.gitignore'd ,所以node_modules文件在Git分支之间共享? 再次,这将如何工作?

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

按照惯例, 不应该添加任何可以从外部源生成或引入的文件,库或二进制文件。 这包括像node_modules ; 因为这是随时可用*一旦你做npm install ,没有理由或激励**要把它放到你的源代码pipe理。 在最坏的情况下,它也会使你的仓库膨胀,用你根本无法控制的东西填充你的差异,不一定要审查。

我不希望NPM项目的不同Git分支包含不同的node_modules文件夹。 我只希望有一个node_modules文件夹,如果一个分支给我适合的依赖关系,我会寻找重新安装依赖关系(并注意到确保别的东西没有出错)。

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

*:假设你正在使用的图书馆没有突然被抽出。 或者,存储库不受巨大的DDoS影响。

**:考虑到今年某些NPM软件包的可靠性不是100%, 可能会有一些激励措施,但这是一个团队和架构驱动的决定,我怀疑将它放在源代码控制中是最理想和方便的方式来处理它。

有两种思想学派,都有优点。

1)从不检查node_modules并在deploy / install上重build

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

积极性:您的存储库要小得多。

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

顾虑:与第三方联系来源 – 阅读有关left-pad事情。 如果一个依赖关系不能被下载,你的整个构build系统就会被挂起来晾干。 “怪脾气和偏执的老计时器”会引用这个理由来检查一切(或者在某处运行你自己的私有NPM)。

分支pipe理 – 就像你在问题中提到的那样,一些分支可能没有相同的依赖关系。 Dev1添加了一个新的function,并使用了一个新的包。 现在Dev2运行dev分支或任何东西,一切都坏了,他们需要知道npm install新的软件包。 更微妙的情况是npm软件包版本发生了变化(现在您需要npm update因为npm install会说没有任何变化),或者node_modules升级到了“新function10”,但他们需要清除所有内容“降级”去修复“之前的bug 43”。 如果你正在积极的发展与2-3团队,注意这一个。

构build时间 – 如果这是一个问题,下载和安装所有内容需要花费一点时间。 或者更长。

2)总是检查一切你可以

这种方法包括node_modules作为回购的一部分。

积极性:不依赖第三方来源。 你有什么需要运行。 你的代码可以永远活着,不pipenpm是down还是repo被删除都没关系。

分支是独立的,因此当Dev2切换到该分支时,Dev1的新function将自动包含在内

部署时间较短,因为没有太多需要安装。

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

拉请求需要额外的照顾。 如果一个软件包与核心代码一起更新(或安装),公关是混乱的,有时难以理解。 “500个文件改变了”,但是你真的更新了一个软件包,并更改了两行核心代码。 它可以帮助分解成两个PR – 一个是一团糟(包更新),一个是实际可审查的(核心代码更改)。 再次,为这一个做好准备。 这些软件包不会经常更改,但是您的代码审查需要更长的时间(或者更多的关注)。

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

结论

这取决于。 (你不觉得那么讨厌吗?)

根据你的团队和你的顾虑,你可能会采取任何一种方法。 两者都有其优点,你会决定哪一个对你更有利。 两者都有缺点,所以你得到位之前要注意那些东西!

具有不同节点模块组的两个分支在一个分支处于开发阶段而另一个分支处于您的生产分支的情况下。 在这种情况下,开发分支将拥有比生产更多的节点模块。 如果我没有错,任何其他情况可能会让你陷入困境。

node_modules送到远程版本控制存储库是不好的做法,因此,无论何时克隆分支或者下载任何添加到package.json的新节点模块,都要依靠npm install

我个人忽略.node_modules,但我有不同的package.json在不同的分支,当我切换我重新安装依赖关系

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