前情回顾

目前已经完成了技术的验证工作、仍然存在一些收尾需要去处理

1.恢复分支场景适配解决

接着上次、完成的仅仅是技术的使用探索、初步验证了可行性满足要求。现在针对一些实际情况进行处理分别是当子项目未储备有相关环境时的处理 如:vuex、elment-ui以及一些通用的样式、如何进行验证等内容

2.简化、丰富使用端

上次子项目调用的配置在多个地方处理、而我们需要统一其在一处、便于简化改造

3.预留提供端全局控制

业务=（显示+数据）、通常我们处理时往往是组件渲染显示集成、相关的业务接口留给了子应用、而实际情况往往是按照业务去划分的、为此做了很多划分处理尝试

实战

达成最终效果

实现了一个可以控制外层控制框样式、路由、兼容自定义及全局控制的 “外壳”、对实现部分的代码做了优化和兼容

对vuex、elment-ui等客户端环境做了判断，作为环境准备阶段
改造引入通用Vue.install插件安装形式调用
调整调用段为动态引入模式、调用端集中配置，具有标准调用能力
控制参数化、提供一种调用扩展能力,为自定义提供控制
最终可以在服务端完成80%的全局工作、和传统的实现统一认证有明显的提升

子应用引入

import {portal} from './consumer.js';

portal.then((res)=>{
  Vue.use(res,
    {
      router, // 传递路由信息
      auth: false, // 是否开启验证登录，
      selfRoute: true, // 开启自定义路由,
      routeLayoutAuto: true, // 自动替换路由窗体组件
      whiteList: [], // 无需验证绕过白名单
      title: '统一门户',
      //sidebarLogo: true, //
      logo: 'https://cube.elemecdn.com/0/88/03b0d39583f48206768a7534e55bcpng.png' // 必须为完整的http访问地址 配
  });
});

//Vue.use(Vuex);

动态调用联邦模块（例子一般都有，如果有问题请联系我）

import { loadComponent } from "./dynamicRemotes";



const pt= loadComponent('centerVue','portal','./portal','http://localhost:9527/centerVue.js')().then(res=>{
  return res;
});
console.log(`返回对象${pt}`);
export const portal=pt;

服务端实现（一定注意、服务端的运行环境为调用端、会存在差异化）

以下为部分实现：

踩坑盲区

你可能构造好了elment-ui的环境、vuex的环境，但是发现了vuex的控制好像还是不正常、那么你踩了第一个坑（两次的多次注册貌似会导致vuex的组件刷新产生问题,同时，在你引入的时候需要将store引入，动态引入modules会导致Store声明异常）
如果你用了svg-icon的组件显示、这块需要特殊去处理一下、最好是能用加载二进制流那种方式，不然会导致图标加载不出
关于认证token信息的交换以及写入，本该是提供标准，子应用自己实现、但此处可以直接预处理即可，因为判断登录由我们本身控制、所以需要实现根据token获取相关用户、权限、菜单、一次就能实现好，写入到子应用域下的缓存中、涉及到相关自定义用户验证（比如原本就由一套机制、需要适配），开放相关回调即可。
另外针对常规js项目、react项目、因为联邦的标准其实是一样的，只需要根据相关的环境去适配即可构造出相应的环境、所以扩展性是可以受控的。

结题

本次虽然是针对vue-cli-service的升级、但主题还是在于解决一个实质性的业务问题，我们具体的技术验证以及思维方式如何进行开展，相关的系列也随着问题的解决得到满足，后续系列更新有待新的问题架构设计还是总结一句技术是为具体的业务场景还有实际情况服务的 本身没有什么老旧之分，并不是vue3出来了我就该升级vue3、这其中涉及到的成本问题，不是靠一个人炫技解决的，所以学习是为了解决将来的问题，提供新思路、如果脱离了初衷，空有屠龙术、却无龙可屠的窘境会常伴左右！！

webpack5 针对vue vue-cli-service 升级指南（三）