本文会分享一个我在实际工作中遇到的案例，从最开始的需求分析到项目搭建，以及最后落地的架构的整个过程。最终实现的效果是使用<code>mono-repo</code>实现了跨项目的组件共享。在本文中你可以看到：
从接到需求到深入分析并构建架构的整个思考过程。
<code>mono-repo</code>的简单介绍。
<code>mono-repo</code>适用的场景分析。
产出一个可以跨项目共享组件的项目架构。
本文产出的架构模板已经上传到GitHub，如果你刚好需要一个mono-repo + react的模板，直接clone下来吧：https://github.com/dennis-jiang/mono-repo-demo
是这么个情况，我还是在那家外企供职，不久前我们接到一个需求：要给外国的政府部门或者他的代理机构开发一个可以缴纳水电费，顺便还能卖卖可乐的网站。主要使用场景是市政厅之类的地方，类似这个样子：
这张图是我在网上随便找的某银行的图片，跟我们使用场景有点类似。他有个自助的ATM机，远处还有人工柜台。我们也会有自助机器，另外也会有人工柜台，这两个地方都可以交水电费，汽车罚款什么的，唯一有个区别是人工那里除了交各种账单，还可能会卖点东西，比如口渴了买个可乐，烟瘾犯了来包中华。
上面只是个概况，要做下来还有很多东西需要细化，柜员使用的功能和客户自助使用的功能看起来差不多，细想下来区别还真不少：
无论是交账单还是卖可乐，我们都可以将它视为一个商品，既然卖商品那肯定有上架和下架的功能，也就是商品管理，这个肯定只能做在柜员端。
市政厅人员众多，也会有上下级关系，普通柜员可能没有权限上/下架，他可能只有售卖权限，上/下架可能需要经理才能操作，这意味着柜员界面还需要权限管理。
权限管理的基础肯定是用户管理，所以柜员界面需要做登陆和注册。
客户自助界面只能交账单不能卖可乐很好理解，因为是自助机，旁边无人值守，如果摆几瓶可乐，他可能会拿了可乐不付钱。
那客户自助交水电费需要登陆吗？不需要！跟国内差不多，只需要输入卡号和姓名等基本信息就可以查询到账单，然后线上信用卡就付了。所以客户界面不需要登陆和用户管理。
从上面这几点分析我们可以看出，柜员界面会多很多功能，包括商品管理，用户管理，权限管理等，而客户自助界面只能交账单，其他功能都没有。
基于上面几点分析，我们的设计师很快设计了两个界面的原型。
这个是柜员界面的：
柜员界面看起来也很清爽，上面一个头部，左上角显示了当前机构的名称，右上角显示了当前用户的名字和设置入口。登陆/登出相关功能点击用户名可以看到，商品管理，用户管理需要点击设置按钮进行跳转。
这个是客户自助界面的：
这个是客户界面的，看起来基本是一样的，只是少了用户和设置那一块，卖的东西少了可乐，只能交账单。
现在需求基本已经理清楚了，下面就该我们技术出马了，进行技术选型和架构落地。
首先我们需要考虑的一个问题就是，柜员界面和客户界面是做在一个网站里面，还是单独做两个网站？因为两个界面高度相似，所以我们完全可以做在一起，在客户自助界面隐藏掉右上角的用户和设置就行了。
但是这里面其实还隐藏着一个问题：柜员界面是需要登陆的，所以他的入口其实是登陆页；客户界面不需要登陆，他的入口应该直接就是售卖页。如果将他们做在一起，因为不知道是柜员使用还是客户使用，所以入口只能都是登录页，柜员直接登陆进入售卖页，对于客户可以单独加一个“客户自助入口”让他进入客户的售卖页面。但是这样用户体验不好，客户本来不需要登陆的，你给他看一个登录页可能会造成困惑，可能需要频繁求教工作人员才知道怎么用，会降低整体的工作效率，所以产品经理并不接受这个，要求客户一进来就需要看到客户的售卖页面。
而且从技术角度考虑，现在我们是一个<code>if...else...</code>隐藏用户和设置就行了，那万一以后两个界面差异变大，客户界面要求更花哨的效果，就不是简单的一个<code>if...else...</code>能搞定的了。所以最后我们决定部署两个站点，柜员界面和客户界面单独部署到两个域名上。
既然是两个站点，考虑到项目的可扩展性，我们创建了两个项目。但是这两个项目的UI在目前阶段是如此相似，如果我们写两套代码，势必会有很多组件是重复的，比较典型的就是上面的商品卡片，购物车组件等。其实除了上面可以看到这些会重复外，我们往深入想，交个水费，我们肯定还需要用户输入姓名，卡号之类的信息，所以点了水费的卡片后肯定会有一个输入信息的表单，而且这个表单在柜员界面和客户界面基本是一样的，除了水费表单外，还有电费表单，罚单表单等等，所以可以预见重复的组件会非常多。
作为一个有追求的工程师，这种重复组件肯定不能靠CV大法来解决，我们得想办法让这些组件可以复用。那组件怎么复用呢？提个公共组件库嘛，相信很多朋友都会这么想。我们也是这么想的，但是公共组件库有多种组织方式，我们主要考虑了这么几种：
再创建一个项目，这个项目专门放这些可复用的组件，类似于我们平时用的<code>antd</code>之类的，创建好后发布到公司的私有NPM仓库上，使用的时候直接这样：
但是，我们需要复用的这些组件跟<code>antd</code>组件有一个本质上的区别：我们需要复用的是业务组件，而不是单纯的UI组件。<code>antd</code>UI组件库为了保证通用性，基本不带业务属性，样式也是开放的。但是我这里的业务组件不仅仅是几个按钮，几个输入框，而是一个完整的表单，包括前端验证逻辑都需要复用，所以我需要复用的组件其实是跟业务强绑定的。因为他是跟业务强绑定的，即使我将它作为一个单独的NPM包发布出去，公司的其他项目也用不了。一个不能被其他项目共享的NPM包，始终感觉有点违和呢。
另一个方案是<code>git submodule</code>，我们照样为这些共享组件创建一个新的Git项目，但是不发布到NPM仓库去骚扰别人，而是直接在我们主项目以<code>git submodule</code>的方式引用他。<code>git submodule</code>的基本使用方法网上有很多，我这里就不啰嗦了，主要说几个缺点，也是我们没采用他的原因：
本质上<code>submodule</code>和主项目是两个不同的<code>git repo</code>，所以你需要为每个项目创建一套脚手架(代码规范，发布脚本什么的)。
<code>submodule</code>其实只是主项目保存了一个对子项目的依赖链接，说明了当前版本的主项目依赖哪个版本的子项目，你需要小心的使用<code>git submodule update</code>来管理这种依赖关系。如果没有正确使用<code>git submodule update</code>而搞乱了版本的依赖关系，那就呵呵了。。。
发布的时候需要自己小心处理依赖关系，先发子项目，子项目好了再发布主项目。
<code>mono-repo</code>是现在越来越流行的一种项目管理方式了，与之相对的叫<code>multi-repo</code>。<code>multi-repo</code>就是<code>多个仓库</code>，上面的<code>git submodule</code>其实就是<code>multi-repo</code>的一种方式，主项目和子项目都是单独的<code>git仓库</code>，也就构成了<code>多个仓库</code>。而<code>mono-repo</code>就是<code>一个大仓库</code>，多个项目都放在<code>一个git仓库</code>里面。现在很多知名开源项目都是采用的<code>mono-repo</code>的组织方式，比如<code>Babel</code>，<code>React</code> ,<code>Jest</code>, <code>create-react-app</code>, <code>react-router</code>等等。<code>mono-repo</code>特别适合联系紧密的多个项目，比如本文面临的这种情况，下面我们就进入本文的主题，认真看下<code>mono-repo</code>。
其实我之前写<code>react-router</code>源码解析的时候就提到过<code>mono-repo</code>，当时就说有机会单独写一篇<code>mono-repo</code>的文章，本文也算是把坑填上了。所以我们先从<code>react-router</code>的源码结构入手，来看下<code>mono-repo</code>的整体情况，下图就是<code>react-router</code>的源码结构：
我们发现他有个<code>packages</code>文件夹，里面有四个项目：
react-router：是<code>React-Router</code>的核心库，处理一些共用的逻辑
react-router-config：是<code>React-Router</code>的配置处理库
react-router-dom：浏览器上使用的库，会引用<code>react-router</code>核心库
react-router-native：支持<code>React-Native</code>的路由库，也会引用<code>react-router</code>核心库
这四个项目都是为<code>react</code>的路由管理服务的，在业务上有很强的关联性，完成一个功能可能需要多个项目配合才能完成。比如修某个BUG需要同时改<code>react-router-dom</code>和<code>react-router</code>的代码，如果他们在不同的Git仓库，需要在两个仓库里面分别修改，提交，打包，测试，然后还要修改彼此依赖的版本号才能正常工作。但是使用了<code>mono-repo</code>，因为他们代码都在同一个Git仓库，我们在一个<code>commit</code>里面就可以修改两个项目的代码，然后统一打包，测试，发布，如果我们使用了<code>lerna</code>管理工具，版本号的依赖也是自动更新的，实在是方便太多了。
<code>lerna</code>是最知名的<code>mono-repo</code>的管理工具，今天我们就要用它来搭建前面提到的共享业务组件的项目，我们目标的项目结构是这个样子的：
<code>lerna</code>初始化很简单，先创建一个空的文件夹，然后运行：
这行命令会帮我创建一个空的<code>packages</code>文件夹，一个<code>package.json</code>和<code>lerna.json</code>，整个结构长这样：
<code>package.json</code>中有一点需要注意，他的<code>private</code>必须设置为<code>true</code>，因为<code>mono-repo</code>本身的这个Git仓库并不是一个项目，他是多个项目，所以他自己不能直接发布，发布的应该是<code>packages/</code>下面的各个子项目。
<code>lerna.json</code>初始化长这样：
<code>packages</code>字段就是标记你子项目的位置，默认就是<code>packages/</code>文件夹，他是一个数组，所以是支持多个不同位置的。另外一个需要特别注意的是<code>version</code>字段，这个字段有两个类型的值，一个是像上面的<code>0.0.0</code>这样一个具体版本号，还可以是<code>independent</code>这个关键字。如果是<code>0.0.0</code>这种具体版本号，那<code>lerna</code>管理的所有子项目都会有相同的版本号----<code>0.0.0</code>，如果你设置为<code>independent</code>，那各个子项目可以有自己的版本号，比如子项目1的版本号是<code>0.0.0</code>，子项目2的版本号可以是<code>0.1.0</code>。
现在我们的<code>packages/</code>目录是空的，根据我们前面的设想，我们需要创建三个项目：
<code>common</code>：共享的业务组件，本身不需要运行，放各种组件就行了。
<code>admin-site</code>：柜员站点，需要能够运行，使用<code>create-react-app</code>创建吧
<code>customer-site</code>：客户站点，也需要运行，还是使用<code>create-react-app</code>创建
创建子项目可以使用<code>lerna</code>的命令来创建：
也可以自己手动创建文件夹，这里<code>common</code>子项目我就用<code>lerna</code>命令创建吧，<code>lerna create common</code>，运行后<code>common</code>文件夹就出现在<code>packages</code>下面了：
这个是使用<code>lerna create</code>默认生成的目录结构，<code>__test__</code>文件夹下面放得是单元测试内容，<code>lib</code>下面放得是代码。由于我是准备用它来放共享组件的，所以我把目录结构调整了，默认生成的两个文件夹都删了，新建了一个<code>components</code>文件夹：
另外两个可运行站点都用<code>create-react-app</code>创建了，在<code>packages</code>文件夹下运行：
几个项目都创建完后，整个项目结构是这样的：
按照<code>mono-repo</code>的惯例，这几个子项目的名称最好命名为<code>@<主项目名称>/<子项目名称></code>，这样当别人引用你的时候，你的这几个项目都可以在<code>node_modules</code>的同一个目录下面，目录名字就是<code>@<主项目名称></code>，所以我们手动改下三个子项目<code>package.json</code>里面的<code>name</code>为：
上面的图片可以看到，<code>packages/</code>下面的每个子项目有自己的<code>node_modules</code>，如果将它打开，会发现很多重复的依赖包，这会占用我们大量的硬盘空间。<code>lerna</code>提供了另一个强大的功能：将子项目的依赖包都提取到最顶层，我们只需要先删除子项目的<code>node_modules</code>再跑下面这行命令就行了：
删除已经安装的子项目<code>node_modules</code>可以手动删，也可以用这个命令：
<code>lerna bootstrap --hoist</code>虽然可以将子项目的依赖提升到顶层，但是他的方式比较粗暴：先在每个子项目运行<code>npm install</code>，等所有依赖都安装好后，将他们移动到顶层的<code>node_modules</code>。这会导致一个问题，如果多个子项目依赖同一个第三方库，但是需求的版本不同怎么办？比如我们三个子项目都依赖<code>antd</code>，但是他们的版本不完全一样：
这个例子中<code>admin-site</code>和<code>customer-site</code>需要的<code>antd</code>版本都是<code>3.1.0</code>，但是<code>common</code>需要的版本却是<code>4.9.4</code>，如果使用<code>lerna bootstrap --hoist</code>来进行提升，<code>lerna</code>会提升用的最多的版本，也就是<code>3.1.0</code>到顶层，然后把子项目的<code>node_modules</code>里面的<code>antd</code>都删了。也就是说<code>common</code>去访问<code>antd</code>的话，也会拿到<code>3.1.0</code>的版本，这可能会导致<code>common</code>项目工作不正常。
这时候就需要介绍<code>yarn workspace</code> 了，他可以解决前面说的版本不一致的问题，<code>lerna bootstrap --hoist</code>会把所有子项目用的最多的版本移动到顶层，而<code>yarn workspace</code> 则会检查每个子项目里面依赖及其版本，如果版本不一样则会留在子项目自己的<code>node_modules</code>里面，只有完全一样的依赖才会提升到顶层。
还是以上面这个<code>antd</code>为例，使用<code>yarn workspace</code>的话，会把<code>admin-site</code>和<code>customer-site</code>的<code>3.1.0</code>版本移动到顶层，而<code>common</code>项目下会保留自己<code>4.9.4</code>的<code>antd</code>，这样每个子项目都可以拿到自己需要的依赖了。
<code>yarn workspace</code>使用也很简单，<code>yarn 1.0</code>以上的版本默认就是开启<code>workspace</code>的，所以我们只需要在顶层的<code>package.json</code>加一个配置就行：
然后在<code>lerna.json</code>里面指定<code>npmClient</code>为<code>yarn</code>，并将<code>useWorkspaces</code>设置为<code>true</code>：
使用了<code>yarn workspace</code>，我们就不用<code>lerna bootstrap</code>来安装依赖了，而是像以前一样<code>yarn install</code>就行了，他会自动帮我们提升依赖，这里的<code>yarn install</code>无论在顶层运行还是在任意一个子项目运行效果都是一样的。
现在我们建好了三个子项目，要启动CRA子项目，可以去那个目录下运行<code>yarn start</code>，但是频繁切换文件夹实在是太麻烦了。其实有了<code>lerna</code>的帮助我们可以直接在顶层运行，这需要用到<code>lerna</code>的这个功能：
比如我们在顶层运行了<code>lerna run start</code>，这相当于去每个子项目下面都去执行<code>yarn run start</code>或者<code>npm run start</code>，具体是<code>yarn</code>还是<code>npm</code>，取决于你在<code>lerna.json</code>里面的这个设置：
如果我只想在其中一个子项目运行命令，应该怎么办呢？加上<code>--scope</code>就行了，比如我就在顶层的<code>package.json</code>里面加了这么一行命令：
所以我们可以直接在顶层运行<code>yarn start:aSite</code>，这会启动前面说的管理员站点，他其实运行的命令还是<code>lerna run start</code>，然后加了<code>--scope</code>来指定在管理员子项目下运行，<code>@mono-repo-demo/admin-site</code>就是我们管理员子项目的名字，是定义在这个子项目的<code>package.json</code>里面的：
然后我们实际运行下<code>yarn start:aSite</code>吧：
看到了我们熟悉的CRA转圈圈，说明到目前为止我们的配置还算顺利，哈哈~
现在项目基本结构已经有了，我们建一个公共组件试一下效果。我们就用<code>antd</code>创建一个交水费的表单吧，也很简单，就一个姓名输入框，一个查询按钮。
这个组件写好了，我们就在<code>admin-site</code>里面引用下他，要引用上面的组件，我们需要先在<code>admin-site</code>的<code>package.json</code>里面将这个依赖加上，我们可以去手动修改他，也可以使用<code>lerna</code>命令：
这个命令效果跟你手动改<code>package.json</code>是一样的：
然后我们去把<code>admin-site</code>默认的CRA圈圈改成这个水费表单吧：
然后再运行下：
嗯？报错了。。。如果我说这个错误是我预料之中的，你信吗😜
仔细看下上面的错误，是报在<code>WaterForm</code>这个组件里面的，错误信息是说：jsx语法不支持，最后两行还给了个建议，叫我们引入<code>babel</code>来编译。这些都说明了一个同问题：babel的配置对common子项目没有生效。这其实是预料之中的，我们的<code>admin-site</code>之所以能跑起来是因为CRA帮我们配置好了这些脚手架，而<code>common</code>这个子项目并没有配置这些脚手架，自然编译不了。
我们这几个子项目都是<code>React</code>的，其实都可以共用一套脚手架，所以我的方案是：将CRA的脚手架全部eject出来，然后手动挪到顶层，让三个子项目共享。
首先我们到<code>admin-site</code>下面运行：
这个命令会将CRA的<code>config</code>文件夹和<code>scripts</code>文件夹弹出来，同时将他们的依赖添加到<code>admin-site</code>的<code>package.json</code>里面。所以我们要干的就是手动将<code>config</code>文件夹和<code>scripts</code>文件夹移动到顶层，然后将CRA添加到<code>package.json</code>的依赖也移到最顶层，具体CRA改了<code>package.json</code>里面的哪些内容可以通过<code>git</code>看出来的。移动过后的项目结构长这样：
注意CRA项目的启动脚本在<code>scripts</code>文件夹里面，所以我们需要稍微修改下<code>admin-site</code>的启动命令：
现在我们使用<code>yarn start:aSite</code>仍然会报错，所以我们继续修改<code>babel</code>的设置。
首先在<code>config/paths</code>里面添加上我们<code>packages</code>的路径并<code>export</code>出去：
然后修改<code>webpacka</code>配置，在<code>babel-loader</code>的<code>include</code>路径里面添加上这个路径：
现在再运行下我们的项目就正常了：
最后别忘了，还有我们的<code>customer-site</code>哦，这个处理起来就简单了，因为前面我们已经调好了整个主项目的结构，我们可以将<code>customer-site</code>的其他依赖都删了，只保留<code>@mono-repo-demo/common</code>，然后调整下启动脚本就行了：
这样客户站点也可以引入公共组件并启动了。
最后要注意的一点是，当我们修改完成后，需要发布了，一定要使用<code>lerna publish</code>，他会自动帮我更新依赖的版本号。比如我现在稍微修改了一下水费表单，然后提交：
现在我试着发布一下，运行
运行后，他会让你选择新的版本号：
我这里选择一个<code>minor</code>，也就是版本号从<code>0.0.0</code>变成<code>0.1.0</code>,然后<code>lerna</code>会自动更新相关的依赖版本，包括：
<code>lerna.json</code>自己版本号升为<code>0.1.0</code>：
<code>common</code>的版本号变为<code>0.1.0</code>：
<code>admin-site</code>的版本号也变为<code>0.1.0</code>，同时更新依赖的<code>common</code>为<code>0.1.0</code>：
<code>customer-site</code>的变化跟<code>admin-site</code>是一样的。
上面这种发布策略，我们修改了<code>common</code>的版本，<code>admin-site</code>的版本也变成了一样的，按理来说，这个不是必须的，<code>admin-site</code>只是更新依赖的<code>common</code>版本，自己的版本不一定是升级一个<code>minor</code>，也许只是一个<code>patch</code>。这种情况下，<code>admin-site</code>的版本要不要跟着变，取决于<code>lerna.json</code>里面的<code>version</code>配置，前面说过了，如果它是一个固定的指，那所有子项目版本会保持一致，所以<code>admin-site</code>版本会跟着变，我们将它改成<code>independent</code>就会不一样了。
然后我再改下<code>common</code>再发布试试：
在运行下<code>lerna publish</code>，我们发现他会让你自己一个一个来选子项目的版本，我这里就可以选择将<code>common</code>升级为<code>0.2.0</code>，而<code>admin-site</code>只是依赖变了，就可以升级为<code>0.1.1</code>:
具体采用哪种策略，是每个子项目版本都保持一致还是各自版本独立，大家可以根据自己的项目情况决定。
这个<code>mono-repo</code>工程我已经把代码清理了一下，上传到了GitHub，如果你刚好需要一个<code>mono-repo + react</code>的项目模板，直接clone吧：https://github.com/dennis-jiang/mono-repo-demo
下面我们再来回顾下本文的要点：
事情的起源是我们接到了一个外国人交水电费并能卖东西的需求，有柜员端和客户自助端。
经过分析，我们决定将柜员端和客户自助端部署为两个站点。
为了这两个站点，我们新建了两个项目，这样扩展性更好。
这两个项目有很多长得一样的业务组件，我们需要复用他们。
为了复用这些业务组件，我们引入了<code>mono-repo</code>的架构来进行项目管理，<code>mono-repo</code>特别适合联系紧密的多个项目。
<code>mono-repo</code>最出名的工具是<code>lerna</code>。
<code>lerna</code>可以自动管理各个项目之间的依赖以及<code>node_modules</code>。
使用<code>lerna bootstrap --hoist</code>可以将子项目的<code>node_modules</code>提升到顶层，解决<code>node_modules</code>重复的问题。
但是<code>lerna bootstrap --hoist</code>在提升时如果遇到各个子项目引用的依赖版本不一致，会提升使用最多的版本，从而导致少数派那个找不到正确的依赖，发生错误。
为了解决提升时版本冲突的问题，我们引入了<code>yarn workspace</code>，他也会提升用的最多的版本，但是会为少数派保留自己的依赖在自己的<code>node_modules</code>下面。
我们示例中两个CRA项目都有自己的脚手架，而<code>common</code>没有脚手架，我们调整了脚手架，将它挪到了最顶层，从而三个项目可以共享。
发布的时候使用<code>lerna publish</code>，他会自动更新内部依赖，并更新各个子项目自己的版本号。
子项目的版本号规则可以在<code>lerna.json</code>里面配置，如果配置为固定版本号，则各个子项目保持一致的版本，如果配置为<code>independent</code>关键字，各个子项目可以有自己不同的版本号。
Lerna官网：https://lerna.js.org/
Yarn workspace: https://classic.yarnpkg.com/en/docs/workspaces/
文章的最后，感谢你花费宝贵的时间阅读本文，如果本文给了你一点点帮助或者启发，请不要吝啬你的赞和GitHub小星星，你的支持是作者持续创作的动力。
欢迎关注我的公众号进击的大前端第一时间获取高质量原创~
“前端进阶知识”系列文章：https://juejin.im/post/5e3ffc85518825494e2772fd
“前端进阶知识”系列文章源码GitHub地址： https://github.com/dennis-jiang/Front-End-Knowledges