乐趣区

关于微前端:为什么-qiankun-不能和-vite-一起使用

qiankun 简介

qiankun 是蚂蚁金服开源的欠缺的微前端解决方案,禁受过大量的线上零碎的考验及打磨,是国内使用率较高的微前端框架之一,它具备不限度技术栈、齐备的款式隔离、js 沙箱与资源预加载等特点,如其官网所说的一样:

可能是你见过最欠缺的微前端解决方案🧐

qiankun 为什么不能和 vite 一起应用?

在 qiankun 官网上,能够找到如何疾速接入 qiankun 的教程,但仅有 webpack 的示例而没有 vite 的,根本原因在于 vite 与 qiankun 无奈很好的联合在一起,其起因次要有以下两方面:

  1. vite2 不反对 runtime publicPath,这项能力在 webpack 中由内置变量 __webpack_public_path__ 提供,runtime publicPath是 qiankun 加载子利用的外围 (由 import-html-entry 模块提供),用于预加载及引入异步脚本
  2. esm 会使 qiankun 的 js 沙箱生效,qiankun 外部的 js 沙箱应用将 window 对象进行了代理,以避免全局作用域被净化,但 esm 模块始终具备本人独立的顶级作用域,也就是说它拜访到的 window 是全局作用域下的,而不是 qiankun 沙箱中提供的代理 window,尽管能够通过在生产环境打包为 umd 格局的形式来防止应用 esm,但有些轻重倒置了

解决方案

社区

为了解决以上问题,社区中涌现出了诸如 vite-plugin-qiankun、vite-plugin-qiankunjs、vue-cli-plugin-vite-qiankun 等解决方案,以其中用户量最多的 vite-plugin-qiankun 来看,它对于以上两个问题的解决方案如下

  1. base 写死以解决预加载及动静导入的问题,此计划治标不治本,只能通过给定的 base 拜访,子利用部署的一旦变动就须要进行更改
  2. 提供 helper 裸露主利用传递的 代理 window 变量

尝试

针对 vite 不反对 runtime publicPath的问题,我也曾试着去解决过,这就是 @sh-winter/vite-plugin-qiankun,此我的项目中,通过批改 vite2 中外部注入的 __VITE_ASSET____VITE_PRELOAD__标记,实现了 runtime publicPath,然而此形式侵入了 vite 的外部解决逻辑,随着 vite 的更新,随时可能会生效,所以不举荐应用

将来

runtime publicPathvite3.2 版本中失去了反对,后续就能够通过 experimental.renderBuiltUrl 来达成此目标

esm 的反对目前没有解决办法,只有等到 ShadowRealm (相似于 nodejs 的 vm 模块) 提案正式落地了,好消息是此提案曾经进入第三阶段了,具体正式利用也不远了,让咱们一起期待吧😉

退出移动版