老版本的前端组件库，由部分统一的npm包与零碎的组件，使用docz利用mdx文件生成文档网站。基于以下几个原因要升级：
升级原因
问题一： 更新组件后,组件的预览文档在docz的项目包中需要二次修改，有时还需要引入额外的组件依赖，文档更新的时效及流程会变的繁琐。
预期：组件与文档同在一个包中，更新了组件，联动预览页进行更新,每个预览应用会做为组件平台的子应用，通过动态注册子应用、动态添加菜单来发布到预览系统中
问题二： 组件库无法适时更新且包越来越大，更新的时间节点十分笨重,一周更新一次小版本，一月更新中版本。
预期： 各项目组件及组件发布解偶,可以自由发布后有专人审核
问题三： 在项目开发的过程中会生产一些业务组件，需要在当前项目中快速提取一个/多个组件
预期： 只要开发者为项目中的组件编写了组件预览文档，可以快速把项目中的预览文档发布到线上，项目中组件可做为npm组件包发布到npm私库中
架构设计
前端
- 组件平台（主应用）：采用微服务方式把多个组件聚合起来，并提供菜单与导航页面
- 组件预览页（子应用）：组件预览采用mdx的形式，将每一个组件的readme文档通过webpack单独的编译，将编译后的产物发布到服务器上通过一个前端中间件发布，再提供路由用一个主应用聚合起来
- 组件管理页（子应用）： 管理子应用的存货状态
客户端
- 工具脚手架：编写一个脚手架完成客户端发布审核的功能,可以完成对组件预览的解析并打包成一个微服务子应用、对组件的打包发布、对公共依赖的处理，
- 子引用模板 ：需要对qiankun的状态进行区分处理，还需要提供页面提交审核功能。
- 组件： 需要编写对应的.md文件
后端
- node服务：提供一个主应用跟子应用的静态服务，提供组件的信息，提供组件预览页面的发布，审核等功能
- 数据库：保存子应用的信息，与菜单路由的存活情况。
技术细节
微服务化技术方案
- qiankun
- webpack5 Module Federation (计划改造. . .)
命令行脚手架开发
- 项目模板克隆：从远程拉取配置模板或者采用问询式的方法生成，并根据配置模板拉取项目的模板。
- 打包组件： 放入一个webpack,并依赖相应的plugin,loader，安装完cli后可脱离原先项目直接对js文件解析打包。
- 预览页打包：根据md文件创建路由文件(多入口),webpack创建额外的complier对象，config.entry指向脚手架模板,模板中读取路由并通过配置文件引入md文件
- MD文档的解析：使用webpack对应的loader,@mdx-js/react @mdx-js/vue等
- 上传：complier对象执行run方法后根据outputpath上传后即可
- 自定义解析： 在md文档中用标识做代码块展示，codepen链接等通过自写loader实现
依赖处理
1.预览页
- 将用到的主流框架打包出一个单独的dll引用。
- 子引用中通过判断qiankun的状态来决定是否引入
2.打包组件
- 处理掉node_modules引入的其他包
- 这里遇到过一个问题，hooks组件发布到Npm无法使用，原因是打包时会额外有一个react.production.min.js包
版本管理
用客户端命令行做基建实现一个MonoRepo的管理
