前情摘要

近一个月的梳理选型、各自都有功能近似的基础版本,基本为

• 前端 vue+elment-ui 多数都为vue-cli-service 脚手架 【种子项目vue-elment-admin】
• 服务端 java 微服务架构 基本趋向于阿里系配置### Spring Cloud Alibaba 、 Nacos用作注册中心
• 数据库 mysql作为应用开发端、实际服务涉及到常见oralce、mongodb、sqlserver、redis等

初步筛选已基本满足前端部分的一致性、暂未涉及跨框架如react、angular等、所以在选型阶段已经避免了复杂问题的处理 现阶段主要为快速达成统一登录授权管理融合、并以此为基础剔除掉各个应用的冗余功能用户、角色、单位、菜单、日志等、集中深化业务应用关键功能，便于后续多人开展工作，此时主要为最小耗费融合改造进行技术调研；

1. 微前端 场景不太适应、技术体系相对单一且不存在已实际部署的应用，考虑到实际的技术耗费以及有些硬性指标不做约束无法达成或偏离初衷
2. 联邦模块 主组件可以共享、包括layout、样式、业务逻辑、埋点、函数、可达成多态且集中可控的目的 子应用的开发改造，调整最小且能达成引用更新、分离部署互不干扰的目的 联邦模块的使用需要升级webpack5、但此版本属于重大更新,分离抽提了部分内部集成、升级未知性不可预见、好在有磨刀不误砍柴工的特性、一个升级完成，后续批量即可 webpack5据说比4性能强一些、但改造后没感觉有什么明显提升、只是考虑到新特性最终还是必然会用到，这个坑这次不趟，下次就要被逼着趟了 【人手不足的硬伤一直伴随着我】

思路目的

实际需要达成的目的主要是什么

1. 短时间内就需整合出效果
2. 风格统一、至少是外层菜单统一，目前前端融合部署、选型部分系于我一身、另外吐槽一句，专职做服务端或是前端的技术轴、我又沟通障碍了
3. 融合多个应用为一个整体应用、但部署及业务规划是分离的，从这点来说比较贴近微前端的思想
4. 一些非vue体系的应用需要重新开发规划改造、得尽力预留时间去处理
5. 在后续人员补充前、尽量把整体骨架处理好

升级指南

可以看到升级的内容差异性包含有几部分 其中vue升级部分

升级

npm i   @vue/cli@next @vue/cli-service@next  @vue/cli-plugin-babel@next  @vue/cli-plugin-eslint@next   -D 

如果包含有代码规范验证、则需要对以下做升级

   "eslint": "7.5.0",
   "eslint-plugin-vue": "^8.7.1"

同时更新规则 .eslintrc.js 升级后一些规则发生了变化，需要做出处理

新增 主要是webpack5和4的兼容问题

  node-polyfill-webpack-plugin: "^1.1.4"
  @vue/preload-webpack-plugin: "^2.0.0"

移除 script-ext-html-webpack-plugin: "2.1.3"

vue.config 兼容改造

//发布公共组件
const   fede=require('./src/config/fede');
const NodePolyfillPlugin = require('node-polyfill-webpack-plugin')
const preload = require('@vue/preload-webpack-plugin')

以下是配置改造部分

如果你.sass样式文件中需要用到js变量 样式丢失了 恭喜你踩坑成功

注意不兼容的写法、粗暴的办法就是注释掉

补充一句,如果你用脚手架做了分包处理、此处的共享组件引入会有问题，需要进行特殊处理才行

以上就是vue 升级相关的处理，到此处正常运行和编译暂未发现新问题

坑点

每次升级都是一场惊心动魄的脑细胞死亡争夺战，工程化带来便利的同时，对npm包的问题不多说 antd的彩蛋、padleft、开源注入ZZ言论 同时伴随着开源作者或傲娇或迫于生计或其他断更太监时有发生 往往包不兼容问题或没有替代方案都是需要待考察验证的、也许一个问题绕不过，就可能导致方案夭折 最后引用一句 实践是检验真理的唯一标准 技术YYDS

总结陈词

目前只是前端单个项目的升级、后续会扩展到第二个应用，也就是消费者端部分 至于具体在实现过程中还存在有什么问题、以待后续分享！