php项目目次商定技巧_将 node_modules 目录放入 Git 仓库的优点

作者是Google 的一位工程师，他先容了他们团队将 Node.js 项目的 node_modules 目录加入到Git仓库的好处，值得借鉴。
除了 Node.js 项目，像 PHP 项目的 vendor 目录，也可以考虑下这样做。

下面是原文：

在我现在的事情之前，我在每个公司的每个团队都有一个约定：不要将你的 node_modules 文件夹放到你的版本掌握系统（在本文的别的部分我将其称为 "Git"...）中。
这彷佛是一个可靠的建议，有多个缘故原由。

•node_modules 中的代码并不是由团队直接编写的。

•node_modules 中的代码常日相称大，会在 git diffs 和 pull requests 操作时引入很多不必要的代码，将代码审核变得繁芜。

•node_modules 中的代码可以很随意马虎地通过 npm install 来得到。

我目前在谷歌的Chrome DevTools团队事情，我们将 node_modules 文件夹放入了 Git 中。
起初，这让我以为很诧异，但我逐渐创造，这样做有很多的的好处。

一旦你将 node_modules 文件夹放入了 Git 中, 你在运行代码之前就不须要运行安装步骤。
这不仅对本地开拓职员有用，对你在持续集成平台上运行的任何机器人（例如CircleCI、GitHub Actions等）也有很大的加速浸染。
这是机器人构建完备可以忽略的一步。
我在本地从头开始运行一个完全的 npm install 至少须要1-2分钟，而在机器人构建时，这可能须要花费更长的韶光。
如果你设置机器人在在每次 pull request 时都运行，机器人可能每天都会运行50次以上。
将node_modules 文件夹放入了 Git 中可以节省大量的韶光（和带宽！
）。

将node_modules 文件夹放入了 Git 中可以担保两个运行代码的开拓者运行的是完备相同的代码和完备相同的依赖关系集。
虽然，这可以通过 package-lock.json 文件或其他工具来管理，虽然这些工具都很少涌现问题，但有时会涌现一个小版本号的变革而导致的问题。
一旦依赖项位于git中，您就不可能利用除这些依赖项之外的任何其他内容运行，每个开拓职员都将运行完备相同的代码库。

当 git diff 向我显斧正在添加到项目中的全部代码时，我惊异地创造我对添加依赖关系有了更清楚的认识。
这使我们对依赖关系包做出了贡献，以帮助减少它们在磁盘上的文件大小，并更好地理解依赖对我们的包大小的影响。

我在前面提到，人们把 git diff 中显示的大量的依赖库的代码看作是在版本掌握中添加依赖关系的一个缺陷，我也承认这可能是这种方法的一个缺陷，但我创造展示依赖库的代码也是有好处的。
添加一个额外的依赖项是由于我不想自己编写几行代码，这是我过去常常做的事情。
但现在我考虑得更多，由于我可以看到正在增加的代码，并且可以反思这是否值得。

把稳：这并不虞味着我们不要用第三方依赖关系！
有些时候，增加一个依赖关系是值得的。
但在版本掌握中看到增加的代码使我对这样做有更多的考虑--本钱不再是不可见的的。

不能回避这样一个事实，即如果一个开拓职员在修正中增加了一个新的依赖关系，在差异中可能会有很多代码。
我们检讨的一个依赖项是 TypeScript，每次我们更新时，git diff 都很弘大，坦率地说这不值得看（除了CHANGELOG）。
我们想出了一个规则来帮助我们：一个更新 node_modules 的改动不能触及代码库中的任何其他代码。
因此，如果我用最新的版本更新 node_modules/typescript ，如果node_modules之外的任何其他文件夹被改变，我就会被我们的工具警告。

这条规则在大多数时候对我们很有用，由于任何依赖于新的或更新的依赖关系的事情都可以分成两个步骤：

•更新依赖关系

•在代码中利用该依赖关系

有些时候这并不见效；更新 TypeScript 可能须要我们更新一些代码来修复新版TypeScript 与当前代码不兼容的一些缺点。
在这种情形下，我们就不须要遵守该规则。

就像软件工程中的任何事情一样，大多数 "规则 "都是辅导方针，我们能够在须要时绕过它们。

臭名昭著的 left-pad 事宜，即一个盛行的npm包溘然从版本库中删除，导致各地的构建中断，这不会影响到一个将所有的依赖关系都添加到 git 仓库中的团队。
虽然他们仍旧须要处理 "我们该如何处理这个不受支持的依赖" 的长期影响，但在短期内，他们的构建不会中断，也不会影响他们发布新功能。

如果我创建一个新的代码库，或者加入一个刚刚开始第一个版本的小公司，我会强烈主见将 node_modules 加入到版本掌握中。
虽然这须要一些韶光来适应，但根据我过去两年的事情履历，我上面列出的好处远远超过了这样做的缺陷。

[1] Why you should check-in your node dependencies: https://www.jackfranklin.co.uk/blog/check-in-your-node-dependencies/