原文网址：https://www.takeshape.io/arti…
原文作者：ANDREW SPROUSE
这是一个重大的决定
在 TakeShape，我们非常关注开发人员的生产力。我们是一个资源有限的小型团队，因此值得花时间考虑如何更快，更高效地合作。在最近重构我们的构建过程时，我们做出了一个重大决定：我们将抛弃 Yarn 并改用 pnpm 来管理我们的依赖项并运行我们的脚本。这是关于我们如何做出该决定以及迄今为止如何使我们受益的故事。
最初，TakeShape 的代码库分散在多个 Git 存储库中。每个软件包都是独立开发的，并且彼此依赖。从理论上讲，这是理想的设置。在实践中，我们发现所有东西都是相互依赖的，我们真的希望能够同时测试和发布所有软件包。当我们为其中一个软件包发行新版本时会遇到失败，但是会忘记在依赖它的其他项目中更新该版本。
最终，我们意识到，在保持项目的分离性和依赖性时，monorepo 是正确的权衡。我们所有的软件包（如 Web 客户端，前端路由库和 CLI）都存在一个可测试且可部署的单元中。我们的包可以使用package.json 中的 link：语法相互依赖。
这在很大程度上是有效的，但是我们仍然发现管理我们的 monorepo 的部分是乏味的。这在一定程度上是因为我们的 monorepo 中的每个包都用自己的包管理器管理自己的依赖关系，json和它自己的 lock 文件。即使每个包使用相同的开发工具链，如 eslint、Jest、Typescript 和 Babel，每个包单独声明这些 devdependency，这个工具链必须在我们所有的包中保持最新。我们决定不使用Yarn 的工作区特性来解决这个问题，因为这将需要抛弃每个包的 lock 文件，而使用单个工作区范围的 lock 文件。
避免幻像依赖也比实际需要更加棘手。当您的代码导入未在 package.json 中声明的包时，就会产生幻像依赖。假设您将 Package A 添加到依赖于 Package B 的项目中。由于 Yarn 将所有程序包都保留在 node_modules 的根目录下，因此您可以导入和使用 Package B ，而无需将其完全放在 package.json 中。尽管不是很常见，但这是一个错误的做法，它确实会减慢调试过程的速度，除非您记得有意地检查它。
我们的 monorepo 也使我们的 CI 管道比所需的更加复杂。首先，我们并行化了 CircleCI 构建，以加快慢速 Webpack 构建。但是，随着我们的 monorepo 的增长，为每个构建分别安装依赖项的开销也在增加。为每个构建安装依赖项成为瓶颈。作为回应，我们使用自己编写和维护的 CircleCI 脚本巩固了构建过程，以减少使用工作。最终，我们得到了一组脆弱的 CI 脚本来对任何包进行剪裁、测试和构建更改。
我们真正需要的是一种递归安装软件包，提升所有共享依赖关系并运行脚本以进行 lint，测试和构建的方法。我们知道 Yarn 并不能为我们扩展，因此我们开始考虑替代方案：
- 如果我们保留 Yarn 并添加 Lerna 怎么办？添加 Lerna 可以解决 CI 脚本编写中的一些问题，但不能解决幻像依赖项或重复的 devDependencies 带来的问题。
- 如果我们添加了 Lerna 并使用了 Yarn Workspaces，该怎么办？工作区将解决共享开发人员依赖关系并自动链接依赖关系的问题。但是将所有 node_modules 提升到项目根目录只会加剧幻想依赖项的风险，并导致某些模块和工具出现问题。
- 如果我们升级到 Yarn 2.0 并使用……其他……该怎么办？Yarn 2.0 确实令人兴奋。它具有很多很酷的功能，包括 Plug’n’Play（PnP）。PnP 可以解决幻想依赖项的问题，但是它可能与某些需要文件访问的依赖项不兼容。Yarn 2.0 与 Lerna 不兼容；相反，它具有插件架构。这些插件有可能解决我们对 CI 脚本的需求，但它们还不够成熟，无法自信地用于生产中。
- 如果我们用 pnpm 替换 Yarn 怎么办？根据
pnpm的说法，它存在“[使用] 硬链接和符号链接仅一次在磁盘上保存模块的一个版本”。这种组织node_modules的方法可以防止幻象依赖并避免在吊装时出现其他问题。它可以解决与 Yarn 2.0 的 PnP 相同的问题，但是由于它仅使用链接，因此具有更广泛的兼容性。pnpm 还包含与 Lerna 类似的过滤功能。
最后，pnpm 对我们来说最有意义。我们发现 pnpm 的递归命令和 –filter 标志消除了我们对像 Lerna 这样的单独软件包的需要。将 Babel，ESLint 和 Jest 之类的共享开发人员依赖项无缝移动到我们项目的顶层，现在可以从单个共享源更新这些软件包。在切换过程中，我们甚至在我们的项目中发现并修复了多个幻象依赖项！
采用 pnpm 后，我们复杂的 CircleCI 管道被简化为一个作业。结果，我们将整个可计费的 CircleCI 分钟减少了大约一半！我们认为通过调整设置可以获得更多的好处，但这是一个很好的开始。
当然，每个决策都需要权衡利弊，pnpm 也不例外。虽然 pnpm 由 zkochan 积极维护，但与 Yarn 或 NPM 相比，它是一个不太受欢迎的项目。虽然微软使用的是 PNPM，但它没有像 Yarn 从 Facebook 获得的直接企业赞助那么高。和 pnpm 有自己的 lockfile 格式，所以它不直接兼容 Yarn 或 NPM。我们很难知道未来会发生什么，但如果我们需要从 pnpm 中脱离出来，这将是一个比我们希望的更大的任务。
尽管听起来很傻，但 Yarn 不需要自定义脚本的“运行”命令，这使我们宠坏了，因此我们不得不重新训练我们的肌肉记忆。这是一个很小的折衷，但它确实增加了我们的团队切换这样一个基本的日常工作流程的成本。
但是，归根结底，这些成本远远超过了 pnpm 对我们的堆栈所做出的改进。现在，我们可以比以往更快，更有效地进行工作，并且需要付出的代价更少。
pnpm 可能不是适用于每个项目或每个堆栈的正确工具，但是如果您遇到与我们的 monorepo 相同的任何问题，请看看并考虑将其作为替代方法。