Ledger Live Monorepo 项目：第 1 部分 – 问题（让它变得痛苦）| 分类帐

在本博客文章系列中，Ledger Live 开发人员 Valentin De Almeida 向我们讲述了多年来 Ledger Live 代码库的演变。 在这篇博文中，您将了解到它最初是基于多存储库的，我们在此过程中遇到的问题，以及为什么它需要发展为单一存储库架构。 在接下来的博客文章中，我们将解释这个主要迁移项目是如何进行的。 

一点点历史 

Ledger 在 2020 年和 2021 年的增长非常显着。 我们积极招募新人才，将我们的团队从少数开发人员扩大到 20 多名开发人员。 这意味着许多新工程师加入了现有项目。 随着我们团队的快速成长，我们遇到了必须快速解决的新挑战。 尽管遇到了这些新的困难，我们仍然专注于我们的目标，并继续完成出色的工作。

我们退后一步，研究了当越来越多的人加入该项目时出现的新问题。 在这些新挑战中，我们可以列出以下需求：

• 更简单的流程。
• 为传入和外部贡献者提供更好的指南。
• 一套统一的工具。
• 更好的依赖管理。
• 集中的开源贡献。

最先进的技术：迁移之前

最初，直到去年，Ledger Live 都基于多存储库架构，适用于移动和桌面前端及其背后的所有逻辑。 以这种方式工作并不是一个有意识的决定，但这只是一个没有真正架构主导的扩展项目的结果。 Ledger Live 是一个将各种组件整合为一个项目，旨在为我们的 Nano 用户提供最好、最安全的应用程序，这一点也反映在代码库中。

我们现有的流程充其量只是不稳定，主要是因为几年前我们只有 6 或 7 名开发人员。 由于涉及的各方较少，沟通变得更加容易，我们就成功了。 尽管如此，我们的工作方式仍然存在一些痛点，特别是在开发人员体验和发布过程方面。

开发体验瓶颈

依赖

由于我们项目的性质，我们同时处理多个存储库，并且它们之间存在依赖关系。 以下是一个快速概述：

Ledger 开源库由业务逻辑使用，然后由桌面和移动应用程序使用。 但这些应用程序也使用开源库，并使用同一库的两个不同版本（例如 @ledgerhq/errors 例如）会破坏应用程序。

我们需要在一侧升级版本，然后发布库（是的，发布到 npm！！！），如果不起作用，请重试。 我们开始依赖 yalc 符号链接项目，只要我们没有多层依赖关系（例如，从开源库到业务逻辑，然后从业务逻辑到应用程序），这基本上就可以了。 我们尝试着与 yarn link 也是如此，但 React Native 似乎注定了它的命运。

测试

使用不同项目的所有最新代码进行集成测试几乎是不可能的。 由于我们需要将库发布到注册表，因此使用最新的代码测试所有组件是一场噩梦

我们还必须维护多个具有重复逻辑的 CI。

上下文切换

总是在多个代码编辑器/项目/目录之间移动使开发体验看起来非常薄弱。

发布流程瓶颈

版本

处理不同项目的版本控制很困难，尤其是当存在多层依赖关系时。

释放

由于项目被分割，发布跟踪变得很复杂，我们必须管理不同项目的发布

由于项目被分成不同的存储库，因此不可能实现发布过程的自动化。

当然，持续交付在此时是不可想象的。

可能的解决方案？

环顾四周寻找灵感，单一存储库架构似乎是我们所缺少的核心部分。 它将实现更好的开发过程。 围绕这个架构构建的工具可以帮助我们实现缺失的部分（发布、自动化、版本控制……）。

但是，什么是 Mono 存储库？

从本质上讲，Mono 存储库是一个项目，它将所有其他相关项目（应用程序、库、工具）封装在一个文件夹/git 项目下。 它允许更好的依赖管理、工具的统一（如代码样式和打字稿配置）、集中的持续集成、集成测试、使用的打包的统一版本（例如反应）......

由于它是一个相当不可知的系统，因此一些功能留给我们去发现和实现。 希望有一些很棒的社区工具可以帮助我们在构建中添加编排（顺序构建，对 CI 有帮助）、版本控制、变更日志生成......这将完成我们在发布过程中缺少的内容。

缺点

Mono 存储库在多个开发人员或开发团队同时处理多个项目且它们之间存在依赖关系的情况下有意义。 然而，它在设置阶段增加了一些复杂性（特别是对于已经启动并运行且具有 4 年历史且积极开发的项目）。 值得一提的是，该项目在磁盘空间方面变得更大（就像更大）。 所有项目现在都位于同一文件夹和所有依赖项下。 哪些测试是强制性的？ 什么时候触发它们？

优点

在评估了时间、成本和我们的雄心壮志的可行性之后，以下是这次过渡的一些预期好处：

• 改进的依赖关系管理：使用 monorepo，可以更轻松地管理不同项目之间的依赖关系，因为它们都存储在同一个存储库中。 这可以减少对纱线链接或 yalc，并更轻松地确保所有项目都使用正确版本的依赖项。
• 更好的代码组织：单一存储库可以更轻松地组织代码，因为所有项目及其依赖项都存储在单个存储库中。 更容易理解不同的项目如何组合在一起以及它们如何相互依赖。
• 改进的开发人员体验：单一存储库可以使开发人员更轻松地处理多个项目，因为他们不需要在不同的代码库或存储库之间切换。 它还可以使运行集成测试变得更容易，因为所有代码都存储在同一个存储库中。
• 增强的自动化和持续交付：使用 monorepo，可以更轻松地自动化构建、测试和发布代码等任务。 这有助于简化发布流程，更容易实现持续交付。
• 提高了开发速度。 由于不同的团队在同一个存储库中工作，因此他们不需要等到发布才验证结果，从而加速了集成。

结论

总体而言，实施 monorepo 结构有助于改进开发流程、简化发布流程并增强开发人员体验。

在本系列的下一篇博客文章中，我们将向您介绍这个主要迁移项目是如何进行的、我们使用的工具、我们所做的选择、结果等等。 请继续关注第 2 部分：工具！

---

瓦伦丁·德·阿尔梅达
开发者体验和核心技术 – Ledger Live

• SEO 支持的内容和 PR 分发。 今天得到放大。
• PlatoData.Network 垂直生成人工智能。 赋予自己力量。 访问这里。
• 柏拉图爱流。 Web3 智能。 知识放大。 访问这里。
• 柏拉图ESG。 碳， 清洁科技, 能源， 环境， 太阳能， 废物管理。 访问这里。
• 柏拉图健康。 生物技术和临床试验情报。 访问这里。
• Sumber: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain