将 node_modules 目录放入 Git 仓库的优点

推荐一篇文章 Why you should check-in your node dependencies[1]

作者是 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 中。起初，这让我觉得很诧异，但我逐渐发现，这样做有很多的的好处。

优点

不需要npm安装

一旦你将 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 事件

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

总结

如果我创建一个新的代码库，或者加入一个刚刚开始第一个版本的小公司，我会强烈主张将 node_modules 加入到版本控制中。虽然这需要一些时间来适应，但根据我过去两年的工作经验，我上面列出的好处远远超过了这样做的缺点。

引用链接

[1] Why you should check-in your node dependencies: