单一代码库
- 好处
- 可见性（Visibility）：每个人都可以看到其他人的代码，这样可以带来更好的协作和跨团队贡献——不同团队的开发人员都可以修复代码中的bug，而你甚至都不知道这个bug的存在。
- 更简单的依赖关系管理（Simpler dependency management）：共享依赖关系很简单，因为所有模块都托管在同一个存储库中，因此都不需要包管理器。
- 唯一依赖源（Single source of truth）：每个依赖只有一个版本，意味着没有版本冲突，没有依赖地狱。
- 一致性（Consistency）：当你把所有代码库放在一个地方时，执行代码质量标准和统一的风格会更容易。
- 共享时间线（Shared timeline）：API或共享库的变更会立即被暴露出来，迫使不同团队提前沟通合作，每个人都得努力跟上变化。
- 原子提交（Atomic commits）：原子提交使大规模重构更容易，开发人员可以在一次提交中更新多个包或项目。
- 隐式CI（Implicit CI）：因为所有代码已经统一维护在一个地方，因此可以保证持续集成[3]。
- 统一的CI/CD（Unified CI/CD）：可以为代码库中的每个项目使用相同的CI/CD[4]部署流程。
- 统一的构建流程（Unified build process）：代码库中的每个应用程序可以共享一致的构建流程[5]。
- 缺陷(我们在版本控制工具、构建系统和持续集成流水线方面达到了设计极限。这些问题可能会让一家公司走上多代码库的道路：)
- 性能差（Bad performance）：单一代码库难以扩大规模，像git blame这样的命令可能会不合理的花费很长时间执行，IDE也开始变得缓慢，生产力受到影响，对每个提交测试整个repo变得不可行。
- 破坏主线（Broken main/master）：主线损坏会影响到在单一代码库中工作的每个人，这既可以被看作是灾难，也可以看作是保证测试既可以保持简洁又可以跟上开发的好机会。
- 学习曲线（Learning curve）：如果代码库包含了许多紧密耦合的项目，那么新成员的学习曲线会更陡峭。
- 大量的数据（Large volumes of data）：单一代码库每天都要处理大量的数据和提交。
- 所有权（Ownership）：维护文件的所有权更有挑战性，因为像Git或Mercurial这样的系统没有内置的目录权限。
- Code reviews：通知可能会变得非常嘈杂。例如，GitHub有有限的通知设置，不适合大量的pull request和code review。
随着前端工程日益复杂，某些业务或者工具库通常涉及到很多个仓库，那么时间一长，多个仓库开发弊端日益显露，由此出现了一种新的项目管理方式——Monorepo。本文主要以 Monorepo 的概念、MultiRepo的弊端、Monorepo 的收益以及Monorepo 的落地这几个角度来认识和学习一下 Monorepo，文末会有思考题，欢迎大家来踊跃讨论。单一代码库（monorepos） vs 多代码库（multirepos）
什么是 Monorepo?
Monorepo 其实不是一个新的概念，在软件工程领域，它已经有着十多年的历史了。概念上很好理解，就是把多个项目放在一个仓库里面，相对立的是传统的 MultiRepo 模式，即每个项目对应一个单独的仓库来分散管理。
现代的前端工程已经越来越离不开 Monorepo 了，无论是业务代码还是工具库，越来越多的项目已经采用 Monorepo 的方式来进行开发。Google 宁愿把所有的代码都放在一个 Monorepo 工程下面，Vue 3、Yarn、Npm7 等等知名开源项目的源码也是采用 Monorepo 的方式来进行管理的。
一般 Monorepo 的目录如下所示，在 packages 存放多个子项目，并且每个子项目都有自己的package.json:
├── packages| ├── pkg1| | ├── package.json| ├── pkg2| | ├── package.json├── package.json
那 Monorepo 究竟有什么魔力，让大家如此推崇，落地如此之广呢？
MultiRepo 之痛
要想知道 Monorepo 的优势，首先得弄清楚之前的开发方式有什么痛点。
之前传统的方式MultiRepo当中，每个项目都对应单独的一个代码仓库。我之前也是用这种方式开发的，是真真切切地感受到了这种方式带来的诸多弊端。现在就和大家一一分享一下。
1.代码复用
在维护多个项目的时候，有一些逻辑很有可能会被多次用到，比如一些基础的组件、工具函数，或者一些配置，你可能会想: 要不把代码直接 copy 过来，多省事儿！但有个问题是，如果这些代码出现 bug、或者需要做一些调整的时候，就得修改多份，维护成本越来越高。
那如何来解决这个问题呢？比较好的方式是将公共的逻辑代码抽取出来，作为一个 npm 包进行发布，一旦需要改动，只需要改动一份代码，然后 publish 就行了。
但这真的就完美解决了么？我举个例子，比如你引入了 1.1.0 版本的 A 包，某个工具函数出现问题了，你需要做这些事情：
- 去修改一个工具函数的代码
- 发布1.1.1版本的新包
- 项目中安装新版本的 A。
可能只是改了一行代码，需要走这么多流程。然而开发阶段是很难保证不出 bug 的，如果有个按钮需要改个样式，又需要把上面的流程重新走一遍……停下来想想，这些重复的步骤真的是必须的吗？我们只是想复用一下代码，为什么每次修改代码都这么复杂？
上述的问题其实是 MultiRepo普遍存在的问题，因为不同的仓库工作区的割裂，导致复用代码的成本很高，开发调试的流程繁琐，甚至在基础库频繁改动的情况下让人感到很抓狂，体验很差。
2.版本管理
在 MultiRepo 的开发方式下，依赖包的版本管理有时候是一个特别玄学的问题。比如说刚开始一个工具包版本是 v1.0.0，有诸多项目都依赖于这个工具包，但在某个时刻，这个工具包发了一个 break change 版本，和原来版本的 API 完全不兼容。而事实上有些项目并没有升级这个依赖，导致一些莫名的报错。
当项目多了之后，很容易出现这种依赖更新不及时的情况。这又是一个痛点。
3.项目基建
由于在 MultiRepo 当中，各个项目的工作流是割裂的，因此每个项目需要单独配置开发环境、配置 CI 流程、配置部署发布流程等等，甚至每个项目都有自己单独的一套脚手架工具。
其实，很容易发现这些项目里的很多基建的逻辑都是重复的，如果是 10 个项目，就需要维护 10 份基建的流程，逻辑重复不说，各个项目间存在构建、部署和发布的规范不能统一的情况，这样维护起来就更加麻烦了。
Monorepo 的收益
说清楚 MultiRepo 的痛点之后，相信你也大概能理解为什么要诞生Monorepo这个技术了。现在就来细致地分析一下Monorepo到底给现代的前端工程带来了哪些收益。
首先是工作流的一致性，由于所有的项目放在一个仓库当中，复用起来非常方便，如果有依赖的代码变动，那么用到这个依赖的项目当中会立马感知到。并且所有的项目都是使用最新的代码，不会产生其它项目版本更新不及时的情况。
其次是项目基建成本的降低，所有项目复用一套标准的工具和规范，无需切换开发环境，如果有新的项目接入，也可以直接复用已有的基建流程，比如 CI 流程、构建和发布流程。这样只需要很少的人来维护所有项目的基建，维护成本也大大减低。
再者，团队协作也更加容易，一方面大家都在一个仓库开发，能够方便地共享和复用代码，方便检索项目源码，另一方面，git commit 的历史记录也支持以功能为单位进行提交，之前对于某个功能的提交，需要改好几个仓库，提交多个 commit，现在只需要提交一次，简化了 commit 记录，方便协作。
Monorepo 的落地
如果你还从来没接触过 Monorepo 的开发，到这可能你会疑惑了: 刚刚说了这么多 Monorepo 的好处，可是我还是不知道怎么用啊！是直接把所有的代码全部搬到一个仓库就可以了吗?
当然不是，在实际场景来落地 Monorepo，需要一套完整的工程体系来进行支撑，因为基于 Monorepo 的项目管理，绝不是仅仅代码放到一起就可以的，还需要考虑项目间依赖分析、依赖安装、构建流程、测试流程、CI 及发布流程等诸多工程环节，同时还要考虑项目规模到达一定程度后的性能问题，比如项目构建/测试时间过长需要进行增量构建/测试、按需执行 CI等等，在实现全面工程化能力的同时，也需要兼顾到性能问题。
因此，要想从零开始定制一套完善的 Monorepo 的工程化工具，是一件难度很高的事情。不过社区已经提供了一些比较成熟的方案，我们可以拿来进行定制，或者对于一些上层的方案直接拿来使用。
其中比较底层的方案比如 lerna，封装了 Monorepo 中的依赖安装、脚本批量执行等等基本的功能，但没有一套构建、测试、部署的工具链，整体 Monorepo 功能比较弱，但要用到业务项目当中，往往需要基于它进行顶层能力的封装，提供全面工程能力的支撑。
当然也有一些集成的 Monorepo 方案，比如nx(官网写的真心不错，还有不少视频教程)、rushstack，提供从初始化、开发、构建、测试到部署的全流程能力，有一套比较完整的 Monorepo 基础设施，适合直接拿来进行业务项目的开发。不过由于这些顶层方案内部各种流程和工具链都已经非常完善了，如果要基于这些方案来定制，适配和维护的成本过高，基本是不可行的。
总结
总而言之，Monorepo 的开发模式就是将各自独立的项目，变成一个统一的工程整体，解决 MultiRepo 下出现的各种痛点，提升研发效率和工程质量。那最后我还有有一个问题，采用 Monorepo 解决了之前的痛点之后，产生了哪些新的问题呢？这些问题可以解决吗？欢迎大家在留言区一起讨论。
若有收获，就点个赞吧
0 人点赞
