本文不着重分析monorepo的优势，记录一下自己把依赖包从multirepos转monorepo方案的思路
囧境
团队内依赖包众多，然而刷包的过程中，同学们重心都在写代码上，忽略了输出一些体验友好的文档。进而导致团队内有新同学加入的时候，经常出现以下对话：
A：你好，能把公司库的文档给我看一下吗，我想先熟悉熟悉。
B：可以的，你去npm镜像源或者gitlab的README.md上看一下，那里有写。
A：......
刚刚加入团队，我也是那个A，没多久后我成了那个B。后来一想，B不好听，我选C！
文档混乱只是其一，再有就是，同学们造轮子的速度很快。一快，模块间的相互依赖就乱了，很多同学在修改一些包的时候，服务意识不足，忽略了对其他包的兼容。而且包的数量一多，就不好管理了。
方案选型
文档站
在尝试解决各个库依赖管理的时候，monorepo方案第一时间确定，没有出现太多岔路。在解决文档输出问题的时候，手动写文档的方案第一时间被pass。考虑到团队内部，大多都是react的项目，使用了umi的脚手架，就联想到了dumi。剩下要做的就是在dumi上联合lerna，构造出我们的依赖包工程。借助dumi的加持，页面以markdown为主，开发调试的过程中，自动写好了文档。dumi自个儿的文档，就是用它自个儿写的，还内置father build打包库，基本满足封装基础库的需求。
包管理工具
原计划，包管理工具使用yarn来操作。在开发过程中，发现随着package的添加，使用lerna + yarn的依赖包管理模式，开发体验受到挑战。对团队内的依赖包数量来说，yarn的速度还是慢了。相互权衡之下，换成了pnpm workspace的模式作为packages管理方案，装包速度大幅提升。另外一个优势就是，使用pnpm就不得不注意幽灵依赖的问题，作为基础包的提供者，这些可能的引起异议的问题，应当都要尽量解决。
CICD自动化少不了
由于团队内的部分包，跟我们的账号体系挂钩，最好的方式就是把文档站点直接部署至内部的测试环境，提供界面预览。测试环境同样面向测试、产品开放，对测试和产品来说，访问频次最多的就是测试环境，这样一来他们能尽量第一时间了解技术团队已有方案和实际效果。
由于平时使用测试环境的多个团队，都有一套各自独立的测试环境，开发人员很容易忘记同步文档站的更新。人为操作比较容易有疏漏，出现过多的疏漏也就违背了我们想要提供一个舒适的库开发模式的初衷。既然做了，那就一步到位。
团队内的发布平台是Jenkins，代码管理平台是gitlab。毋庸置疑，实现自动化的最快方式就是：gitlab web hook + jenkins。在gitlab发送更改event后，过滤master分支，绑定上各个环境各自的Jenkins项目，顺利实现文档站自动更新。
代码修改自动化也要来
“你改是改完了，我们线上有数百个项目，你们改了包我们还得一个一个替换掉，哎......”。依赖包梳理计划开始之初，我就怕最后会听到这样的声音，所以，要堵住悠悠众口。既然做了，那就一步到位。
有部分同学可能进行过antd3升antd4的操作
同样的要调整源代码，antd提供了codemod方案，可以自动改代码。
链接：antd升级说明，antd codemod。就是这样的一行命令能直接修改掉老项目的效果，这应该行。
于是，使用jscodeshift定制我们自己的codemod，梳理我们升级所做出的改动，确定出映射关系，封装成执行代码，在codemod项目中添加好xxx-update命令，并上传至私有npm镜像源。开发者通过npx xxx-update或yarn dlx xxx-update或pnpm dlx xxx-update，即可快速完成对源代码的修改。
推行之路
分享、演示、试点测试、获支持。复制一行代码执行一下的事，都做到这一步了，同学们还不改？天理难容了。还想要codemod工程支持直接修改线上仓库？洗洗睡吧😒
