ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

qiankun 构建插件 @qiankunjs/bundler-plugin 完整指南:Vite 与 Webpack 微应用入口的自动生成

2026/9/21 1:44:23 拓冰建站 浏览量
qiankun 构建插件 @qiankunjs/bundler-plugin 完整指南:Vite 与 Webpack 微应用入口的自动生成 前端微前端【免费下载链接】qiankun Blazing fast, simple and complete solution for micro frontends.项目地址https://gitcode.com/gh_mirrors/qi/qiankun点击查看免费下载qiankunjs/bundler-plugin是 qiankun 官方提供的构建插件包用于为微应用自动生成 qiankun 可识别的 HTML 入口Vite 应用无需任何 UMD/SystemJS 转换即可被 ESM 沙箱原生加载Webpack 应用则被调整为浏览器全局库并自动标记入口脚本。阅读本文后你将掌握该插件在 Vite 5 与 Webpack 4/5 下的安装、配置、选项语义、入口标记规则与生产部署边界并能结合源码理解其底层实现。插件定位谁需要安装它qiankunjs/bundler-plugin只服务于微应用侧它的全部职责是让微应用的构建产物成为 qiankun 可以直接加载的 HTML 入口。主应用不需要安装该插件——主应用侧只依赖qiankun包提供的loadMicroApp、registerMicroApps等运行时 API。该包同时提供 Vite 和 Webpack 两套插件使用时必须选择对应的导入路径插件不会自动判断项目所用的构建工具。这一点与包名容易造成的直觉相反包根路径默认导出的是 Webpack 插件Vite 插件必须从专用子路径导入。安装与版本要求npm install --save-dev qiankunjs/bundler-pluginrc插件支持Vite 5 及以上版本以及Webpack 4 和 Webpack 5。从 packages/bundler-plugin/package.json 可以看到该包将webpack与vite声明为可选对等依赖peerDependenciespeerDependenciesMeta.optional{ peerDependencies: { webpack: ^4.0.0 || ^5.0.0, vite: 5.0.0 }, peerDependenciesMeta: { webpack: { optional: true }, vite: { optional: true } } }因此项目只需安装实际使用的构建工具不会被迫同时引入另一个构建体系。包本身只有一个运行时依赖cheerio用于解析和改写 HTML产物同时提供dist/cjs与dist/esm双格式并分别标记 module 类型见 mark-module-types.mjs。导出路径速查导入路径导出用途qiankunjs/bundler-plugin/viteqiankun具名和默认导出Vite 插件qiankunjs/bundler-pluginQiankunWebpackPlugin具名和默认导出Webpack 插件qiankunjs/bundler-plugin/webpackQiankunWebpackPlugin具名和默认导出Webpack 专用子路径包根入口 packages/bundler-plugin/src/index.ts 仅转发 Webpack 插件而 Vite 插件被单独放在./vite子路径下。最常见的错误就是从包根导入 Vite 插件在 Vite 项目中请务必写import { qiankun } from qiankunjs/bundler-plugin/vite。Vite 插件让原生 ESM 应用成为微应用配置方式Vite 插件不接收任何参数直接调用即可import { qiankun } from qiankunjs/bundler-plugin/vite; import { defineConfig } from vite; export default defineConfig({ plugins: [qiankun()], server: { port: 7101, strictPort: true }, });React 与 Vue 项目可直接与框架插件并列使用例如plugins: [react(), qiankun()]或plugins: [vue(), qiankun()]完整的双框架配置示例见 接入 Vite 应用。插件做了两件事从 packages/bundler-plugin/src/vite/index.ts 的实现可以看到插件通过config()钩子与transformIndexHtml钩子完成两项处理为开发服务器和预览服务器配置允许跨源加载的响应头通过config()钩子返回server与preview的cors: true以及headers: { Access-Control-Allow-Origin: * }。这样主应用可以跨源获取入口 HTML 与整个模块依赖图含动态import()的代码块。在构建产出的 HTML 中标记入口模块脚本通过transformIndexHtmlorder: post在生产构建阶段为与入口 chunk 文件名匹配的script typemodule src...添加entry属性使 qiankun 加载器可以确定性地识别生命周期入口而不是回退到最后一个模块脚本。上述行为被 packages/bundler-plugin/tests/vite-plugin.test.ts 完整覆盖测试验证了 CORS 配置、入口 chunk 匹配标记、无匹配时回退到最后一个模块脚本、尊重已有entry属性、开发环境 HTML 不被改写以及匹配时忽略 URL 上的 query/hash如?v1等细节。入口模块的契约插件不会改变微应用的生命周期代码也不做任何 legacy/SystemJS 转换——qiankun 通过 ESM 沙箱原生加载 Vite 应用。入口模块仍须导出bootstrap、mount和unmount三个生命周期函数并在mount中把应用渲染到props.container内、在unmount中彻底销毁实例export async function bootstrap() {} export async function mount(props) { // render your app into props.container } export async function unmount(props) { // tear your app down }需要留意的是原生 ESM 导出本身就是生命周期约定不应再把生命周期对象赋值给window开发环境下 ESM 引擎会根据生命周期导出自行解析入口因此开发 HTML 无需显式标记Vite 在 dev 转换阶段本就会丢弃未知属性。生产环境 CORS 边界插件仅为 Vite 开发服务器与预览服务器开启 CORS不会替代生产服务器配置。部署后的 HTML、模块含动态导入的代码块、CSS、图片及其他资源仍须由实际服务器或 CDN 返回正确的 CORS 与 MIME 响应头。若请求需要携带 Cookie则不能使用通配符Access-Control-Allow-Origin: *而应在服务端指定明确的允许来源、返回凭据型响应头并在主应用侧配置自定义fetch。完整接入步骤含base子路径部署、__POWERED_BY_QIANKUN__独立运行判断、主应用loadMicroApp加载与卸载、开发/生产验证清单见 接入 Vite 应用。Webpack 插件Classic 脚本构建方案配置方式Webpack 插件需要配合html-webpack-plugin一起使用——由html-webpack-plugin生成 HTML 入口再由 qiankun 插件识别并标记对应的入口脚本const HtmlWebpackPlugin require(html-webpack-plugin); const { QiankunWebpackPlugin } require(qiankunjs/bundler-plugin); module.exports { entry: ./src/index.tsx, plugins: [ new HtmlWebpackPlugin({ template: ./src/index.html }), new QiankunWebpackPlugin({ packageName: sub-app }), ], devServer: { port: 7102, headers: { Access-Control-Allow-Origin: * }, allowedHosts: all, }, };选项说明interface QiankunWebpackPluginOptions { packageName?: string; }选项默认值说明packageName当前package.json的nameClassic 脚本构建输出的全局库名称。插件自动完成的四项输出调整从 packages/bundler-plugin/src/webpack/index.ts 的实现看apply()会依次执行configureOutput()与registerHtmlProcessing()自动设置输出库的名称与格式Webpack 5 下设置output.library { name: packageName, type: window }Webpack 4 下设置output.library packageName、output.libraryTarget window并额外处理output.globalObject window确保库可在浏览器中运行。确保jsonpFunction/chunkLoadingGlobal名称唯一Webpack 4 下将output.jsonpFunction设为webpackJsonp_${packageName}避免多个微应用并存时出现 JSONP 全局冲突Webpack 5 由唯一库名自然保证 chunk 加载全局唯一。将全局对象设为window。在html-webpack-plugin生成的 HTML 中自动标记入口脚本通过compilation钩子获取HtmlWebpackPlugin挂到其alterAssetTags钩子上为入口脚本添加entry属性。因此output.library、output.libraryTarget、output.globalObject以及 Webpack 4 的 JSONP 函数这几个字段应当完全交由插件设置不要在业务 Webpack 配置里再手动指定否则会与插件行为冲突。入口脚本的识别策略插件通过 webpack 的compilation.entrypointsAPI 定位入口 chunkgetEntryChunkFile 中先尝试 Webpack 5 的getEntrypointChunk再回退遍历 chunks 寻找带 runtime 的入口 chunk单入口构建直接标记主入口 chunk 对应的脚本多入口构建按 HTML 文件名path.basename(outputName, .html)匹配同名的 entrypoint兜底策略若自动检测失败标记最后一个脚本标签与 Vite 插件的回退逻辑一致。同时插件会检查脚本是否已带entry属性已有则不再重复标记。以上行为有 packages/bundler-plugin/tests/plugin.test.ts 的集成测试背书测试直接对比 Webpack 4/5 构建产物dist/index.html与期望 fixture而 fixturewebpack4.html、webpack5.html展示的最终形态是vendor.js普通脚本 带entry属性的bundle.js入口脚本。packageName 的稳定性要求packageName是 Classic 脚本构建产物的全局库名称默认取自当前项目package.json的name。若该字段缺失、由工具动态生成或可能在不同构建间变化必须显式设置packageName源码通过读取process.cwd()下的package.json获取默认值读取失败时回退为空字符串此时更需要显式传入。两个容易混淆的概念需要区分清楚packageName用于命名 Webpack 输出的全局库loadMicroApp({ name })用于标识 qiankun 中的应用。默认sandbox: true时两者不必相同——qiankun 会优先从入口脚本的导出或沙箱捕获的全局对象解析生命周期window[name]查找只是兼容旧方式的退路。但如果设置sandbox: false沙箱无法再捕获入口导出qiankun 只能退回window[name]查找此时要么构建产物自行把生命周期赋给window[name]要么让全局库名与主应用传入的name保持一致。运行时公共路径public path入口脚本执行时qiankun 会通过window.__INJECTED_PUBLIC_PATH_BY_QIANKUN__注入微应用入口的基地址。将它赋给 Webpack 的运行时公共路径可确保延迟加载的代码分块从微应用自身的源加载该模块必须先于应用入口中的其他内容导入Webpack 4/5 均适用declare let __webpack_public_path__: string; declare global { interface Window { __POWERED_BY_QIANKUN__?: boolean; __INJECTED_PUBLIC_PATH_BY_QIANKUN__?: string; } } if (window.__POWERED_BY_QIANKUN__ window.__INJECTED_PUBLIC_PATH_BY_QIANKUN__) { __webpack_public_path__ window.__INJECTED_PUBLIC_PATH_BY_QIANKUN__; } export {};CORS 与开发服务器与 Vite 插件不同Webpack 插件不会配置开发服务器的 CORS。webpack-dev-server与生产静态服务器都需要自行返回Access-Control-Allow-Origin响应头允许主应用跨域获取 HTML、脚本和样式外部脚本和样式同样必须提供正确的 CORS 响应头。完整的 Webpack 接入示例生命周期导出、__POWERED_BY_QIANKUN__独立运行、HTML 模板、主应用加载与生产检查清单见 接入 Webpack 应用。入口约束两套插件通用一个 HTML 入口最多只能有一个带entry属性的脚本。它用于指定负责导出微应用生命周期的脚本文档中仍可包含其他普通脚本如 vendor。插件标记入口后请勿再手动添加入口标记也不要在源码中手工书写entry属性建议始终优先使用插件避免手改构建产物。微应用必须导出 生命周期契约bootstrap、mount、unmount且mount在props.container内渲染、unmount彻底清理。生产资源必须满足浏览器的CORS、CSP 与 MIME 类型要求HTML 入口及 qiankun 获取的全部资源需通过 CORS 允许主应用来源重定向后的地址与资源 URL 须可被浏览器访问JavaScript/CSS/模块应返回正确的内容类型。关于入口的解析约定、Classic 脚本与原生 ESM 两种入口的差异、以及 HTML 入口的流式加载机制参见 HTML 入口。常见问题速查Vite 项目从包根导入插件错误。必须从qiankunjs/bundler-plugin/vite导入qiankun包根与./webpack子路径导出的是QiankunWebpackPlugin。Vite 插件能传选项吗不能qiankun()不接收参数CORS 与入口标记均自动完成。开发环境 HTML 需要entry标记吗Vite 开发环境不需要ESM 引擎根据生命周期导出解析入口生产构建由插件自动标记。Webpack 插件会帮我配置 devServer 的 CORS 吗不会需在devServer.headers中自行配置。构建产物里有多个入口脚本违反入口约束请检查是否手动添加了entry属性或存在多 entry 场景下 HTML 文件名与 entrypoint 不匹配的情况。赞分享前端微前端【免费下载链接】qiankun Blazing fast, simple and complete solution for micro frontends.项目地址https://gitcode.com/gh_mirrors/qi/qiankun点击查看免费下载相关推荐qiankun 微前端构建插件 qiankunjs/bundler-plugin 完全指南Vite 与 Webpack 子应用的 HTML Entry 接入qiankun 微前端构建插件 qiankunjs/bundler plugin 完全指南Vite 与 Webpack 子应用的 HTML Entry 接入前端微前端qiankunjs/bundler-plugin 使用指南为 qiankun 微前端自动配置 Webpack 与 Vite 构建产物qiankunjs/bundler plugin 使用指南为 qiankun 微前端自动配置 Webpack 与 Vite 构建产物 本文围绕 qianku前端微前端使用 qiankun 将 Webpack 应用改造为微前端子应用基于 qiankunjs/bundler-plugin 的完整接入指南Webpack 4 / 5使用 qiankun 将 Webpack 应用改造为微前端子应用基于 qiankunjs/bundler plugin 的完整接入指南Webpack 4前端微前端上一篇FilePizza传输协议扩展支持自定义数据格式下一篇H.264码流处理从入门到精通h264bitstream核心API详解创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考