我假设在开发NPM项目时,每个git分支(或您使用的任何版本控制系统)可能指向node_modules文件系统上的不同集合.真的吗？这是如何运作的？它是否会对磁盘空间等造成任何问题？
或者,也许,因为node_modules最常见.gitignore'd,然后node_modules文件在Git分支之间共享？再一次,它会如何/有效？
*请注意,Node.js/NPM与其他平台/语言根本不同,因为依赖关系通常存储在本地,而不是存储在计算机的某个中心位置.
Mak*_*oto 19
按照惯例,不应添加任何可以从外部源生成或引入的文件,库或二进制文件.这包括像node_modules; 因为一旦你这样做就可以随时使用了npm install,所以没有理由或激励**想要把它放到你的源代码控制中.在最坏的情况下,它也会膨胀你的存储库,用你根本无法控制但不一定要查看的东西填充你的差异.
我不希望NPM项目的不同Git分支包含不同的node_modules文件夹.我只期望一个node_modules文件夹,如果一个分支让我适应依赖关系,我会寻找重新安装依赖项(并注意它以确保其他东西没有出错).
作为附录,.gitignoreGit中没有索引或跟踪任何文件或文件夹.如果这些文件或文件夹的内容发生变化,Git就更聪明了.这也意味着,当在分支之间切换时,文件或文件夹的内容.gitignore保持不变.
*:如果你使用的库没有被突然猛拉.或者存储库不受巨大的DDoS的影响.
**:鉴于某些NPM软件包今年的可靠性不是100%,这可能有一些动力,但这是团队和架构驱动的决策,我怀疑将其置于源代码管理中是最大的处理它的理想和方便的方法.
有两种思想流派,都有其优点.
1)永远不要
node_modules在部署/安装时签入和重建
该方法在很大程度上依赖于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作为回购的一部分.
积极因素: 不依赖于第三方来源.你有你需要运行的东西.你的代码可以永久存在,如果npm关闭或者repo被删除也没关系.
分支是独立的,因此Dev2切换到该分支时会自动包含Dev1的新功能
部署时间较短,因为不需要安装太多.
担心: 存储库要大得多.代码克隆需要更长的时间,因为有更多的文件.
Pull Requests需要额外的照顾.如果一个软件包与核心代码一起更新(或安装),那么PR就是一团糟,有时难以理解."500个文件已更改",但实际上您更新了一个包并更改了两行核心代码.它可以帮助分解为两个PR - 一个是混乱(包更新)和一个实际可审查(核心代码更改).再次,为这一个做好准备.这些软件包不会经常更改,但是代码审查需要更长时间(或者更加小心).
操作系统依赖包可能会中断.基本上,安装/编译的任何东西gyp都可以依赖于OS(以及其他).大多数软件包都是"纯JS",只是脚本,无处不在.想象一下,当您部署到Linux时,所有开发人员都在OSX上运行和测试,您无法检查在MAC上编译的那些包,因为它们不能在Linux上运行.一个奇怪的解决方法是将大多数软件包定义为"dev dependencies"(--save-dev)和需要编译为正常的软件包("生产" --save),然后运行npm install --production以便不安装dev依赖项(并且已经存在),但是其他人都是.
结论
这取决于.(你不是一直讨厌听到这个吗？:)
根据您的团队和您的顾虑,您可能采取任何一种方法.两者都有其优点,您将决定哪种更有益于您.两者都有缺点,所以在你得到之前要注意这些!
| 归档时间： |
|
| 查看次数： |
2451 次 |
| 最近记录： |