• 里面的代码node_modules不是由团队直接编写的。
  • 里面的代码node_modules通常很大，会在 git diffs 和 pull requests 中引起很多噪音。
  • node_modules可以通过npm安装轻松复制其中的代码。

我目前在 Google 的 Chrome DevTools 团队工作，我们将node_modules文件夹检查到源代码管理中。起初这让我觉得很不寻常，但我开始相信这种方法有一些主要的好处，我认为更多的人应该考虑。

无需安装 npm

签node_modules入后，无需运行安装步骤即可启动并在代码库上运行。这不仅对本地开发人员有用，而且对您可能在持续集成平台（例如 CircleCI、GitHub Actions 等）上运行的任何机器人都有很大的推动作用。这是机器人可以完全错过的一步。我已经看到项目很容易需要至少 1-2 分钟才能npm install从头开始运行完整的- 而在机器人上可能会更长。如果您认为每个拉取请求和部署都会运行一个机器人，那么您每天可以轻松运行 50 多个机器人。这节省了很多分钟（和带宽！）。

保证复制构建

有你node_modules在保证检查了运行的代码两个开发人员正在运行完全相同的相关性集合的完全相同的代码。是的，这可以通过 package-lock.json 文件或其他工具来管理，但我看到所有这些工具都很少出现错误或允许导致问题的次要版本号略有变化。一旦依赖项在 git 中，您就不可能使用除这些之外的任何东西运行，并且每个开发人员都将运行确切的代码库。

更好地了解您要交付的代码

当 git diff 向我显示要添加到项目中的全部代码时，我对添加依赖项的了解程度让我感到惊讶。这导致我们为工具做出贡献，以帮助减少磁盘上的文件大小，并更好地了解依赖项对我们的包大小的影响。

更多考虑添加依赖项，因为它不是不可见的

我之前提到，人们将 git diff 中的噪音视为向版本控制添加依赖项的不利因素，我承认这可能是这种方法的不利因素，但我发现噪音通常是一个有用的信号。添加一个额外的依赖项，因为我不想自己编写几行代码，这是我以前经常做的事情 - 但现在我考虑得更多，因为我可以看到正在添加的代码，并且可以反思它是否是值得。

注意：这并不意味着我们没有依赖关系！有时添加依赖项是值得的——但看到版本控制中的代码让我更加考虑这样做——成本不再是无形的。

您可以管理大差异

没有人回避这样一个事实，即如果开发人员进行的更改添加了新的依赖项，则差异中可能会有很多噪音。我们签入的依赖项之一是 TypeScript，每次更新它时，git diff 都是巨大的，坦率地说，不值得一看（除了 CHANGELOG）。我们提出了一个对我们有帮助的规则：更新node_modules可能不会触及代码库中的任何其他代码的更改。因此，如果我node_modules/typescript使用其最新版本进行更新，如果外部的任何其他文件夹node_modules发生更改，我们的工具会警告我。

这条规则在大多数情况下都很好地为我们服务，因为任何依赖于新的或更新的依赖项的工作都可以分为两个更改：

  1. 更新依赖
  2. 在代码中使用依赖

有时这不起作用；更新 TypeScript 可能需要我们更新一些代码来修复新版本的 TypeScript 现在检测到的错误。在这种情况下，我们有能力覆盖规则。