前情回顾

话接上回 webpack5 针对vue vue-cli-service 升级指南（一）
当你完成了第一步的操作基本上已经迈出了成功的第一步成功地开始支持vue-cli和webpack5的升级改造工作

后续工作步骤

我的后续工作步骤大概技术验证分成以下几个部分

• 联邦模块的生产者 、消费者 都进行项目升级 vue-cli5 、webpack5
• 在确保正常的调用方式接口、交互、函数、参数传递等无问题的情况下消费者维持原状本着方便消费者的原则,仅升级生产者项目、消费者 以实现Init和get进行动态加载
• 最终交付一个umd组件调用包，类似于接口集、相较于私有库跟微前端 对消费者的要求很低、且难度和总控限制在了生产者侧
• 而我们用很小的代价实现了多子应用菜单、埋点、公共组件、公共方法、统一样式的集成、更重要的是对消费者即子应用的诉求降到最低、更重要的是这种应用可大可小、灵活可控比如：可快速的融合多个子应用（小团队）代价可控、企业级应用（相较于私域Npm、耗费很大精力搞的企业云【其实也就是带业务的物料体系、本人之前的有经历、深受折磨，基本上属于子应用帮做了80%的改造工作】）

虐心之旅

联邦模块的生产者 、消费者 互通

请先容我吐槽、这个问题其实卡了我2天多时间、憧憬后续顺利就纯粹是奢望，别太相信网上的试水教程，大多数都是看别人一顿操作猛如虎、我一顿下来卡在了Bug的鼓点上 我归结为几类情况

1. 用的是webpack的打包编译形式、此类可以忽略不看
2. 生产者 服务端虽然没有异常、但服务没发布成功
3. vue-cli版本的问题、此问题没了解到本质属于误导
4. 官方文档太笼统，主要提供的是思路，但是相关的问题没有剖析
5. 其他教程异常的起因都很零散、不是系统性的，很容易对人产生误导

问题刨析

1. 生产者 、消费者 端 有异常提示包含有“vue”字样、

先注释掉shared试试,其本质也跟打包有关系、如果你对相关的vue、elment-ui做了cdn引用处理、可以在此处处理、若没有,那官方文档也许会给你造成一些误导

2. vue-cli 的模板绝大多数都处理了分包、而设置了分包，会影响提供服务端的服务 表象就是引用时包含“miss”关键字,这代表服务发布出了问题 通过 config.optimization.delete('splitChunks');并注释切片分包逻辑问题得到解决 通过变量确认服务是否正常发布

issues/6318

3. 生产者 端如果publicPath: 'http://localhost:9000/web/'不带你的访问地址、会造成你引用的组件无法正常引用 表象为：“./Button is null” 或者 没有看到请求 这个相对路径与绝对路径有关，会导致内部无法去远程加载、这个在生产环境有坑点、后面有时间再优化方案 当然还有另外一种情况、就是你的组件地址有问题

但你以为这样就结束了嘛，我这样的填坑机器总是会遇到莫名其妙的坑,以上你保证没问题后，容着继续往下看、我又一次被官方demo[给坑了](GitHub - module-federation/module-federation-examples: Implementation examples of module federation , by the creators of module federation)、如果你也看到了示例并且恰好也用了Vue-cli 刚好看到了这个示例

我很确定地告诉你demo本身就有问题 问题的原因分析出来是因为多了一个webpack 我去掉重新引用就正常了、因为vue-cli本身就会包含webpack 类似问题的原因可能是因为webpack版本与你安装的vue-cli-service使用的版本不一致导致的

4. 如果你用Vuex的话、数据交互存在一定问题、这属于内部变量、要交互通信的话上下文属于消费者

还需要额外的接口去进行交互、如果只是要满足适配兼容 最好的办法时用localStorage去进行一些诸如菜单的存储、其他的可以用接口去兼容 我主要是为了满足 子组件可以选择自定义也可以交由消费者组件去控制目录获取这两种模式的切换、目前来看父组件使用vuex store这种方式存在一些小问题需要去兼容

5. 使用 组件调用、没错，你只要切换这个套壳,就能完成风格以及逻辑的切换

具体效果如下【满足用户中心配置菜单、自己设置菜单两种情况】

方法调用,主要针对路由登录验证、切换成主应用,另外一个就是涉及到登录成功后，跳转前的数据预处理，比如：用户信息的重新组件，这能保证你对子应用做最小化的调整、另外就是权限、菜单等的自定义

同时需要注意,加载的一些组件,如你子项目用的都是vue+elment-ui那问题不大，注意兼容Vuex内容,

生产者

消费者

接着动态调用

本着尽量轻度化调用端使用的目的、继续进行后续尝试 基本思路如下，但实施过程中还有部分问题,还有待继续验证，但问题不会太大

经验总结

• 验证过程耗费了比较久时间，原因是具体项目的情况多种多样、和实际的demo型教程差异比较大,此处所有问题都经过验证，并剖析了具体的原因，虽然过程痛苦、但最终和最初的设想完美切合
• 处理问题往往是阶梯形式的,当前首要的目的是什么一定要清楚，脱离了项目情况和工期要求的设计和架构，没啥意义，毕竟留足时间摸鱼充电比较重要

PS

后续会继续将完整地处理以及步骤延续、燕过留痕，各位姥爷,如果有问题可以留言交流，如果能够帮到你，不要吝啬你的随手点赞！！！！ 最后未完待续！！！