需求来源
团队有个需求，B项目和C项目接到一个需求，需求和A项目的类似，直接拷贝A项目的代码再改？这个方案太蠢了，有bug我还得同时改好几个项目，维护成本高，pass
研究了A项目这块需求的代码，发现基本都封装成业务组件了，直接引用组件就可以了，问题就变成了B、C项目引用A项目的代码块(组件)
由此有以下几种方案可以选择：
npm私包
单独创建一个项目，将可复用组件通过npm publish的方式发布到内网verdaccio
优点
实现简单、多项目可复用
缺点
- npm私包更新后，比如修复了某个bug，每个引用它的项目都要升级一次包
- 只适合与业务无关的组件，业务强相关组件不适用
基于缺点2，这个方案也不行
Monorepo
是一种将所有项目放到一个repository的管理方式，目前vue，react等源码都采用这种管理方式，如下图vue3源码仓库目录图片所示，所有包都在packages目录下管理
优点
- 支持不同技术栈的项目集成
- 可以多个项目统一测试、发版
- 不同项目的依赖可能重复，可以将子项目的依赖提取到顶层，无需安装重复依赖
如果多个子项目依赖同一个第三方库，但是依赖版本不一样怎么办？
yarn workspace
缺点
- 改造成本和难度 较大，除了将多个项目都集中到一个仓库，还需要重新设计一套完整的工程体系，比如项目间依赖分析、依赖安装、CICD
- 存在依赖爆炸问题，新人接手项目安装依赖耗时会很长
- 我们的项目都是MultiRepo 模式，每个项目都是一个独立的仓库，而且不同组的前端资源是不集中的，并不适合采用这种方式
模块联邦
webpack5支持的新特性，具体介绍可见webpack.docschina.org/concepts/mo…
优点
- 允许在多个项目中共享依赖、模块、页面甚至应用
- 轻量级的、在运行时，通过全局变量组合，在不同模块之前进行数据的获取
缺点
- 针对要暴露的模块要额外的exposes配置，必须通知所有的模块正确配置
- 本地依赖调试时，在配置了npm link或lerna本地依赖之后，还需要针对remotes配置同名的webpack alias跟tsconfig paths，略有些繁琐。
- 只有webpack5支持，目前我们项目有的是webpack3，有的是webpack4，需要手动升级。升级可能存在的坑：1.配置语法变更2.旧版本支持的插件webpack5不支持或者依赖版本不兼容
目前vite支持通过vite-plugin-federation插件使用模块联邦功能，rollup也增加了模块联邦支持
微前端
终极解决方案，是前端的一种架构，思想类似于微服务。将一个大的前端项目拆分成多个子项目，每个子项目可以独立运行、独立部署，而不同的子项目又可以共享逻辑和数据
优点
- 适用于巨石应用，多个模块或应用解耦
- 独立仓储、独立运行、独立部署
缺点
- 改造时间成本较大，实现方式有多种，包括路由转发，嵌套iframe、构建时组合、运行时组合、web component、qiankun
- 需要考虑不同项目的通信问题，考虑应用是否隔离，不隔离怎么解决资源的重复加载问题
- 需要设计应用的注册、加载、销毁逻辑和工程化逻辑
微前端我在19年做项目的时候就有实现过，综合4种方案下来，由于小组在上个季度完成了webpack5升级，模块联邦无疑是最适合我们团队的方案，如果对webpack5升级感兴趣，可以关注我，后面有时间考虑出一篇
参考文章
