写在前面
2019年9月21号，我参加了第五届FEDAY。在会上，听了王泽老师的分享，我第一次接触到了monorepo这个概念。本文是结合王泽老师的分享，自己进行一点小小的实践后的总结。
本文中的图片，均来自我在团队内部分享时的PPT截图
Monorepo
一种项目管理方式：一个git仓库下管理多个项目，适用于大型团队，框架开发，库开发等。
线上项目现状
一看到monorepo这个概念，我立马想起了自己所在团队的一个repo，目录大概长成下面这样：
这种把所有的项目都放到一个repo下面的好处是：
- 统一技术栈
- 降低团队成员之间的backup成本
- 提升效率
- 每一个人都可以改动任意部分的代码，改动效果实时呈现，调试方便
- 可以在业务开发中，灵活地将代码抽出作为公共模块
- 省去了在多个repo情况下，给团队新成员开通repo权限的时间
大概的repo组织结构是下面这样的：
上图这种repo组织方式对团队现在的业务开发来说，完全足够了，因为每一个页面都还算简单。但是如果要开发一个大型复杂项目，会有问题嘛？
大型复杂项目怎么办
上图的情况在平时的开发中很常见，B项目或许根本就没有时间、人力来回归测试，但是A项目很着急上线，也顾不上这么多。如果业务复杂度小，那这种情况一般不是问题。如果是大型复杂的项目，怎么办呢？项目A重新复制一个基础库a来修改吗？
解决办法就是：版本管理。对组件进行版本管理，托管在公司内部的组件库里面。
到底什么是Monorepo
微软的定义如下：
再来看看著名的babel和React:
我自己的总结如下：
rush.js
微软出品的，一个专门为monorepo打造的项目管理工具。
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等工具进行深入的了解与对比。希望能看到有经验的大佬能够深入分享一下自己的体会。
