使用rush.js管理monorepo

本文首发于公众号：符合预期的CoyPan

写在前面

2019年9月21号，我参加了第五届FEDAY。在会上，听了王泽老师的分享，我第一次接触到了monorepo这个概念。本文是结合王泽老师的分享，自己进行一定实践后的总结。

本文中的图片，均来自我在团队内部分享时的PPT截图

Monorepo

一种项目管理方式：一个git仓库下管理多个项目，适用于大型团队，框架开发，库开发等。

线上项目现状

一看到这个概念，我立马想起了自己所在团队的一个repo，目录大概长成下面这样：

这种把所有的项目都放到一个repo下面的好处是：

1. 统一技术栈

   • 降低团队成员之间的backup成本

2. 提升效率

   • 每一个人都可以改动任意部分的代码，改动效果实时呈现，调试方便
   • 可以在业务开发中，灵活地将代码抽出作为公共模块
   • 省去了在多个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...