为什么我们从Yarn切换到pnpm
这是一个重大的决定
在 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相同的任何问题，请看看并考虑将其作为替代方法。
以上是 为什么我们从Yarn切换到pnpm 的全部内容， 来源链接： utcz.com/a/30935.html
