【问题标题】：How do you share local npm packages with other teams in a single repo?您如何在单个 repo 中与其他团队共享本地 npm 包？
【发布时间】：2019-04-10 18:02:48
【问题描述】：

场景

考虑以下文件夹结构：

/my-service
  /src
  /bin
  /other-package
    /src
    package.json
  package.json

有 2 个 npm 包：一个用于my-service，一个用于other-package。

my-service 依赖于other-package。

my-service 归团队 A 所有，other-package 归团队 B 所有。

请记住，B 团队在 other-package 更改时仍需要部署 my-service。这就是我们考虑共享存储库的原因。

问题

您如何构建这种依赖关系，以使两个团队的开发人员体验都合理？

理想情况下，B 团队只需要安装和构建other-package 并且可以在该目录中执行他们需要的所有操作。

同样，A 团队应该能够使用最新版本的other-package，而在本地开发中的摩擦最小。

选项

我目前正在考虑 2 个选项来解决这个问题，但不知道是否有更好的选择。

本地文件依赖

在此选项中，my-service 的 package.json 如下所示：

  "dependencies": {
    "other-package": "./other-package"
  },
  "scripts": {
    "build": "npm run build:other-package && npm run build",
    "build:other-package": "cd other-package && npm i && npm run build && cd .."
  }

本地压缩包依赖

在此选项中，my-service 的 package.json 如下所示：

  "dependencies": {
    "other-package": "./other-package/other-package-0.0.1.tgz"
  }

在这种情况下，团队B 需要负责在新版本准备好时运行other-package 目录中的npm pack，更新my-service 中的package.json 并将其提交到git。

【问题讨论】：

标签： javascript node.js npm npm-install npm-scripts

【解决方案1】：

将两个包放入单独的存储库中，并在第一个的package.json 文件中放置对第二个的git 存储库的依赖项。如下所示：

"dependencies": {
  "my-other-package": "git://github.com/user/project.git#commit-ish"
}

有关可用语法选项的详细信息，请参阅npm documentation。

这样，两个团队都可以单独处理他们的软件包，并且彼此独立。同时可以通过它的 git url 来引用这个包，你甚至可以通过提供它的commit-ish 来固定一个特定的分支、标签或提交。

如果您使用 GitHub 来管理您的 git 存储库，您还可以使用快捷语法：

"dependencies": {
  "my-other-package": "user/project#commit-ish"
}

这也适用于私有存储库，但仅适用于 GitHub。如果是其他 git 托管解决方案，则需要使用上述语法。

由于您提到依赖团队希望使用最新版本而没有太多摩擦，您可能只是想使用诸如 #master 之类的东西作为 commit-ish。然后在每个npm install 上，您都会获得提交到主分支的最新版本。

请注意，这会导致构建不可重现，因为您无法确定性地预测将安装什么。根据我的个人经验，我宁愿建议将您的依赖项固定到特定的提交上。虽然这需要更多的维护工作，但它会带来可重现和可预测的安装，恕我直言，这很值得，但 YMMV。

这种方法的一大优势是，两个团队不必在发布或类似的事情上相互关心，因为您可以从外部依赖包，而团队管理包甚至都不知道其他人正在使用它。

如果，无论出于何种原因，它绝对必须是一个单一的存储库，并且你不能使用我描述的方法，你可能会对“monorepo”这个术语感兴趣。这基本上是为多个包提供一个（单一）存储库的概念。管理此类 monorepo 的一个工具是 Lerna，您可能需要仔细查看它。

【讨论】：

请记住，B 团队在 other-package 更改时仍需要部署 my-service。这就是我们考虑共享存储库的原因。

【解决方案2】：

那些长期分裂的人应该团结起来；长期团结的人将分裂。

最近我帮助我的团队过渡到 monorepo，将 10 多个 repo 合并为一个。 Monorepo 有一些缺点，当它变得非常大（如谷歌的）时，它会给版本控制设施带来压力。另一方面，它促进了代码共享、重用构建脚本、ci 流、对 git 历史和文件的批处理操作等。

典型的 monorepo 方法平等对待子项目。

/monorepo
  /node_modules <-- shared top level node_modules
  /packages
    /my-service
    /other-package

如果不是出于特殊原因，我建议您将两个包作为兄弟包，而不是父子包。

当完成构建任何一个时，例如 other-package，您将其目录符号链接到顶级 node_modules 目录。

# in /monorepo
ln -s packages/other-package node_modules

如果您愿意尝试lerna.js 之类的工具，它可以帮助您完成繁重的工作。

现在您可以像往常一样指定您的my-service/package.json

  "dependencies": {
    "other-package": "latest"
  }

【讨论】：