为何咱们从Yarn切换到pnpm

原文网址： 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相同的任何问题，请看看并考虑将其做为替代方法。