🤔前言
本文将以微前端 Emp 框架（后面称 Emp）项目成员的角度总结在过去 2020 中探索微前端框架的过程。
欢迎 star： github.com/efoxTeam/em…
✨时间轴，emp 持续投入生产环境
- 5月份 探索阶段初期 分别使用 single spa 搭建
- 6月份上中旬 探索阶段中期 使用 module federation 搭建
- 6月份下旬 确认可行阶段 讨论封装模型
- 7月上中旬 决定使用 cli 模型封装 参考 create react app ，实现远程类型引用模型
- 7月下旬 emp 1.0 版推出，内置dev,build,build -ts 同时配合 antd 用于生产环境
- 8月 增加热更新 增加与优化 demo 用例
- 9月 tuneDtsPlugin 作为独立 webpack plusin 和提高对低版本浏览器兼容性
- 10月 升级webpack 5.1 和增加缓存功能，增加css type 检测 、 css module ts support ，支持cocos
- 11月 emp正式开源，增加github ci测试， init 功能,增加emp支持用例，增加emp跨框架互相调用
- 12月 探索在emp引入esbuild,esm，swc，分离es环境
探索研究阶段
分别调研 Single SPA 和 Module Federation
Single SPA
- 多框架并存、独立开发部署、状态不共享
- 基站方式中心化运行
- 具备完整的脚手架与种子项目
- 部分模块需要改造才能调用 综上所述，引入Single-spa 会增加部署、维护、改造的成本。所以转向研究 Module Federation 。
Module Federation
- 让代码直接在不同项目间通过远程调用 直接共享 任意内容（上下文、状态、组件、方法、模块）
- 去中心化运行
- 共享模块接近 100% 适用、接近 0 改造成本
- 不具备脚手架与种子项目
研究结论：基于 Module Federation 开发一套具有脚手架和种子项目的微前端框架，同时能够让已有项目快速接入。
设计开发阶段
参考 Create React App 开发脚手架及其命令
底层脚手架架构参考成熟的 React 脚手架命令行工具 Create React App。
分别提供了
- dev
- build
- test
- info
- serve
- analyze
- tss 包括但不限于以上命令
emp.config.js
使用 Webpack Chain 暴露内置 Webpack 配置，达到可以在 emp.config.js 进行项目配置
Typescript 远程类型引用
长期使用 React + Typescript 作为技术栈，发现在远程组件调用的时候没有类型，只能重新定义。
所以提出要在远程项目中生成类型文件，然后在本项目中进行调用。保证 Typescript 在微前端上可行。
👨🏻💻总结与感谢
今年是我第一年正式参加工作，有幸作为应届生加入了欢聚时代的业务中台技术中心 Web 组。特别感谢 Ken 大佬和 攀攀大佬、Jeremy 大佬，三位大佬今年一直对我的耐心指导。今年是我目前开发生涯进步最快的一年。
代码结构方面
初入，对自己的代码要求还停留在能用就行的阶段。经过大佬们的指导与耐心 code review 之后，学会如何把封装功能达到高复用、“高内聚，低耦合”有内味，对 MVVM、 MVC 等设计模式有新的见解,不断把《重构》书中开发思想注入到日常开发。当然，期间也在不断巩固自身基础与业务理解、开发能力。
业务开发能力
在参与业务项目的过程中，学习到开发流程的整个闭环: 需求评审->分析产品文档与设计稿->开发排期->结合产品文档与设计稿进行实际开发->ci 自动化部署->域名与国际化部署配置->提测->修复 bug -> 上线 ->修复线上 bug 与持续维护。这个流程严谨而必要。
需要微前端的原因
在我对代码和业务的理解不断深入的时候，Ken 大佬提出要进行微前端架构探索。有了代码结构和业务开发的基础，我瞬间 get 到了微前端的必要性：最高效地复用有价值的功能。
作者
|
Benny Shi |
