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

2次阅读

共计 1158 个字符，预计需要花费 3 分钟才能阅读完成。

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

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

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

vite2 不反对 runtime publicPath，这项能力在 webpack 中由内置变量 __webpack_public_path__ 提供，runtime publicPath是 qiankun 加载子利用的外围 (由 import-html-entry 模块提供)，用于预加载及引入异步脚本
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 来看，它对于以上两个问题的解决方案如下

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

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

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

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

正文完