使用mono-repo实现跨项目组件共享

本文会分享一个我在实际工作中遇到的案例，从最开始的需求分析到项目搭建，以及最后落地的架构的整个过程。最终实现的效果是使用mono-repo实现了跨项目的组件共享。在本文中你可以看到：

1. 从接到需求到深入分析并构建架构的整个思考过程。
2. mono-repo的简单介绍。
3. mono-repo适用的场景分析。
4. 产出一个可以跨项目共享组件的项目架构。

本文产出的架构模板已经上传到GitHub，如果你刚好需要一个mono-repo + react的模板，直接clone下来吧：https://github.com/dennis-jiang/mono-repo-demo

需求

需求概况

是这么个情况，我还是在那家外企供职，不久前我们接到一个需求：要给外国的政府部门或者他的代理机构开发一个可以缴纳水电费，顺便还能卖卖可乐的网站。主要使用场景是市政厅之类的地方，类似这个样子：

这张图是我在网上随便找的某银行的图片，跟我们使用场景有点类似。他有个自助的ATM机，远处还有人工柜台。我们也会有自助机器，另外也会有人工柜台，这两个地方都可以交水电费，汽车罚款什么的，唯一有个区别是人工那里除了交各种账单，还可能会卖点东西，比如口渴了买个可乐，烟瘾犯了来包中华。

需求分析

上面只是个概况，要做下来还有很多东西需要细化，柜员使用的功能和客户自助使用的功能看起来差不多，细想下来区别还真不少：

1. 无论是交账单还是卖可乐，我们都可以将它视为一个商品，既然卖商品那肯定有上架和下架的功能，也就是商品管理，这个肯定只能做在柜员端。
2. 市政厅人员众多，也会有上下级关系，普通柜员可能没有权限上/下架，他可能只有售卖权限，上/下架可能需要经理才能操作，这意味着柜员界面还需要权限管理。
3. 权限管理的基础肯定是用户管理，所以柜员界面需要做登陆和注册。
4. 客户自助界面只能交账单不能卖可乐很好理解，因为是自助机，旁边无人值守，如果摆几瓶可乐，他可能会拿了可乐不付钱。
5. 那客户自助交水电费需要登陆吗？不需要！跟国内差不多，只需要输入卡号和姓名等基本信息就可以查询到账单，然后线上信用卡就付了。所以客户界面不需要登陆和用户管理。

从上面这几点分析我们可以看出，柜员界面会多很多功能，包括商品管理，用户管理，权限管理等，而客户自助界面只能交账单，其他功能都没有。

原型设计

基于上面几点分析，我们的设计师很快设计了两个界面的原型。

这个是柜员界面的：

柜员界面看起来也很清爽，上面一个头部，左上角显示了当前机构的名称，右上角显示了当前用户的名字和设置入口。登陆/登出相关功能点击用户名可以看到，商品管理，用户管理需要点击设置按钮进行跳转。

这个是客户自助界面的：

这个是客户界面的，看起来基本是一样的，只是少了用户和设置那一块，卖的东西少了可乐，只能交账单。

技术

现在需求基本已经理清楚了，下面就该我们技术出马了，进行技术选型和架构落地。

一个站点还是两个站点？

首先我们需要考虑的一个问题就是，柜员界面和客户界面是做在一个网站里面，还是单独做两个网站？因为两个界面高度相似，所以我们完全可以做在一起，在客户自助界面隐藏掉右上角的用户和设置就行了。

但是这里面其实还隐藏着一个问题：柜员界面是需要登陆的，所以他的入口其实是登陆页；客户界面不需要登陆，他的入口应该直接就是售卖页。如果将他们做在一起，因为不知道是柜员使用还是客户使用，所以入口只能都是登录页，柜员直接登陆进入售卖页，对于客户可以单独加一个“客户自助入口”让他进入客户的售卖页面。但是这样用户体验不好，客户本来不需要登陆的，你给他看一个登录页可能会造成困惑，可能需要频繁求教工作人员才知道怎么用，会降低整体的工作效率，所以产品经理并不接受这个，要求客户一进来就需要看到客户的售卖页面。

而且从技术角度考虑，现在我们是一个if...else...隐藏用户和设置就行了，那万一以后两个界面差异变大，客户界面要求更花哨的效果，就不是简单的一个if...else...能搞定的了。所以最后我们决定部署两个站点，柜员界面和客户界面单独部署到两个域名上。

组件重复

既然是两个站点，考虑到项目的可扩展性，我们创建了两个项目。但是这两个项目的UI在目前阶段是如此相似，如果我们写两套代码，势必会有很多组件是重复的，比较典型的就是上面的商品卡片，购物车组件等。其实除了上面可以看到这些会重复外，我们往深入想，交个水费，我们肯定还需要用户输入姓名，卡号之类的信息，所以点了水费的卡片后肯定会有一个输入信息的表单，而且这个表单在柜员界面和客户界面基本是一样的，除了水费表单外，还有电费表单，罚单表单等等，所以可以预见重复的组件会非常多。

作为一个有追求的工程师，这种重复组件肯定不能靠CV大法来解决，我们得想办法让这些组件可以复用。那组件怎么复用呢？提个公共组件库嘛，相信很多朋友都会这么想。我们也是这么想的，但是公共组件库有多种组织方式，我们主要考虑了这么几种：

单独NPM包

再创建一个项目，这个项目专门放这些可复用的组件，类似于我们平时用的antd之类的，创建好后发布到公司的私有NPM仓库上，使用的时候直接这样：

import {
    Cart } from 'common-components';

但是，我们需要复用的这些组件跟antd组件有一个本质上的区别：我们需要复用的是业务组件，而不是单纯的UI组件。antdUI组件库为了保证通用性，基本不带业务属性，样式也是开放的。但是我这里的业务组件不仅仅是几个按钮，几个输入框，而是一个完整的表单，包括前端验证逻辑都需要复用，所以我需要复用的组件其实是跟业务强绑定的。因为他是跟业务强绑定的，即使我将它作为一个单独的NPM包发布出去，公司的其他项目也用不了。一个不能被其他项目共享的NPM包，始终感觉有点违和呢。

git submodule

另一个方案是git submodule，我们照样为这些共享组件创建一个新的Git项目，但是不发布到NPM仓库去骚扰别人，而是直接在我们主项目以git submodule的方式引用他。git submodule的基本使用方法网上有很多，我这里就不啰嗦了，主要说几个缺点，也是我们没采用他的原因：

1. 本质上submodule和主项目是两个不同的git repo，所以你需要为每个项目创建一套脚手架(代码规范，发布脚本什么的)。
2. submodule其实只是主项目保存了一个对子项目的依赖链接，说明了当前版本的主项目依赖哪个版本的子项目，你需要小心的使用git submodule update来管理这种依赖关系。如果没有正确使用git submodule update而搞乱了版本的依赖关系，那就呵呵了。。。
3. 发布的时候需要自己小心处理依赖关系，先发子项目，子项目好了再发布主项目。

mono-repo

mono-repo是现在越来越流行的一种项目管理方式了，与之相对的叫multi-repo。multi-repo就是多个仓库，上面的git submodule其实就是multi-repo的一种方式，主项目和子项目都是单独的git仓库，也就构成了多个仓库。而mono-repo就是一个大仓库，多个项目都放在一个git仓库里面。现在很多知名开源项目都是采用的mono-repo的组织方式，比如Babel，React ,Jest