使用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打造的项目管理工具。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等工具进行更深刻的了解与对比。但愿有经验的大佬可以深刻分享一下本身的体会。

参考资料：

rushjs.io/

www.zhihu.com/question/33…