最近我们也是遇到一个绝大多数sass公司都会遇到的事情， 定制的模块和我们标准的产品线如何整合，不同平台相似的业务性质怎么保证项目的灵活性，高效性。在这个问题中核心是要解决代码复用的问题，一个功能点可能是活动一系列页面+原本的基础能力， 不同业务平台中我们可能有不同的基础能力+相同的功能点，比如用户授权，下单+活动。我们画张图来回顾一下
在这张简略图中，我们可以有很多条线组合出不同的展现形式；
eg：抽奖小程序 = 基础能力+抽奖+应用平台
看到这张图，拍脑袋想一下我们代码的组织形式，对于前端来说可能是n个npm包+业务壳，但是产生一个业务类型，我们就会多至少2个仓库（业务仓库 + 展现形式）。其实我们今天的主角monorepo就是这种场景的最优解，
对与不同的平台我们只是仓库中的一个文件夹。并且依赖也能够隔离，还能有不同的版本。在前端也算是比较成熟的方案有很对优秀的案例。
monorepo
在我的理解中，monorepo是在一个仓库中储存了多个关联项目的代码，每个关联项目可以有独立的依赖，可以方便的共享到不同关联项目的能力。
回到我们前端的依赖管理，npm一定是最普遍的工具了，在远古时期，我们下载项目源码到本地，后来在前端工程中使用cdn，到node出现带来的npm，使用packge.json文件记录项目的依赖，通过命令行，我们可以在npm的源站下载到我们对应的依赖，在不同人共享项目的时间，省去了海量依赖的储存传递，后来又有了yarn，pnpm，都是想更好的解决依赖管理的相关问题，比如yarn创新的扁平式nodemodules，pnpm的软链nodemodules等，这些就不展开说了，有兴趣的同学可以去单独了解。在monorepo的场景下，无疑pnpm是最好的选择。
我们接下来就谈谈uniapp如何和monorepo结合，他和我们普通的monorepo项目有什么区别，其实就是uniapp的pages.json 不支持编译nodemodules中的页面/分包，不然也不会有这一期文章了。
我们当时咨询了uniapp的官方，短期内并不会去花精力去解决实现这个特性，我们只能选择自行实现，或者放弃monorepo，后续在伺机合并仓库。由于我们对uniapp的代码并不熟悉，我们时间又比较紧张，我们想到了一个绝佳的临时方案，我们在pnpm这里得到了灵感，软链，uniapp的pages.json是只能编译src的文件， 我们期望可以编译nodemodules中的文件，哪我们是不是可以把nodemodules和src做一个映射， 有了这个思路，我们来具体看一下如何去实现。
我们记录依赖的是package.json, 比如我们weixin平台和douyin平台都有包含一个活动的分包，我们在开始uniapp的编译cli前，先去做一下软链接， 将公共的分包指向src目录下，这样uniapp就可以访问到我们的依赖文件，老规矩看图
达到如图的效果，我们就能实现共享代码的能力了。
完成了核心的能力，我们还要做一些善后，比如软链不能上传到git仓库， 在编辑器搜索中过滤掉重复的结果
