共计 1791 个字符，预计需要花费 5 分钟才能阅读完成。
本文首发于公众号：符合预期的 CoyPan
写在前面
2019 年 9 月 21 号，我参加了第五届 FEDAY。在会上，听了王泽老师的分享，我第一次接触到了 monorepo 这个概念。本文是结合王泽老师的分享，自己进行一定实践后的总结。
本文中的图片，均来自我在团队内部分享时的 PPT 截图
Monorepo
一种项目管理方式：一个 git 仓库下管理多个项目，适用于大型团队，框架开发，库开发等。
线上项目现状
一看到这个概念，我立马想起了自己所在团队的一个 repo，目录大概长成下面这样：
这种把所有的项目都放到一个 repo 下面的好处是：
统一技术栈
- 降低团队成员之间的 backup 成本
提升效率
- 每一个人都可以改动任意部分的代码，改动效果实时呈现，调试方便
- 可以在业务开发中，灵活地将代码抽出作为公共模块
- 省去了在多个 repo 情况下，给团队新成员开通 repo 权限的时间
大概的 repo 组织结构是下面这样的：
上图这种 repo 组织方式对团队现在的业务开发来说，完全足够了，因为每一个页面都还算简单。但是如果要开发一个大型复杂项目，会有问题嘛？
大型复杂项目怎么办
上图的情况在平时的开发中很常见，B 项目或许根本就没有时间、人力来回归测试，但是 A 项目很着急上线，也顾不上这么多。如果业务复杂度小，那这种情况一般不是问题。如果是大型复杂的项目，怎么办呢？项目 A 重新复制一个基础库 a 来修改吗？
解决办法就是：版本管理。对组件进行版本管理，托管在公司内部的组件库里面。
到底什么是 monorepo
微软的定义如下：
再来看看著名的 babel 和React:
我自己的总结如下：
rush.js
微软出品的，一个专门为 monorepo 打造的项目管理工具。https://rushjs.io。
rush.js 解决了两个重要的问题：phantom dependencies 和 doppelgangers。我们先来看看这两个问题。
phantom dependencies
没有在 package.json 里指定安装，却可以在项目中被引用的依赖。
在 npm3.0 以后，是可以的。这是因为：npm 原有的树形结构，造成了依赖冗余和路径过深。npm3 后开始扁平化，把原来不同级的依赖变成了同级依赖。这样我们在项目中就能直接引用到了。
phantom dependencies 的问题：
- 依赖版本混乱
- 依赖丢失
常规解决思路：制定代码规范；使用代码检查工具来避免这种情况发生。但是 ……
doppelgangers
同一个依赖被多次安装，导致项目臃肿，打包变慢。
rush.js 的 Symlink 机制
Rush会将项目依赖全部都安装在 repo 根目录的 common/temp 下，然后提供 symlink 到各个项目中去引用。原本的项目中，依然会保持原有的 node_modules 结构。
看一个例子：
Rush 保证只会在项目的 node_modules 中保留 package.json 中声明过的依赖的 Symlink。这样，自然解决了phantom dependencies
rush 会将所有的依赖都安装在一个地方，对于不同版本的同一个依赖，rush 会同时安装所有的依赖版本，并且提供 symlink 供项目使用，这样，自然就解决了 doppelgangers。
另外，rush 会对依赖的版本（SemVer）进行智能判断，防止重复安装依赖包。例如，两个项目同时依赖了一个第三方库，第一个项目依赖的是：^1.2.0，另一个依赖的版本号是：1.5.0。rush 安装依赖时，只会安装 1.5.0。
rush.js 的简单使用介绍
下面简单介绍一下 rush.js 的使用。
- rush.json
- rush build
- rush update
- rush change
- rush publish
写在后面
本文介绍了 monorepo，同时对 rush.js 进行了简单的探索。monorepo 已经有很多的案例了，比如上面提到的 babel,react。monorepo 的管理也有很成熟的工具了，如著名的lerna。经过一些小小的研究，我对 rush.js 的印象是： 很规范，但是对于团队来说，上手成本真的不小。
目前我所在团队负责的业务，并没有适合 monorepo 的场景，所有也没有对 rush.js,lerna 等工具进行更深入的了解与对比。希望有经验的大佬能够深入分享一下自己的体会。
参考资料：
https://rushjs.io/
https://www.zhihu.com/questio…
