Umi MFSU 的 normal 与 eager 两种策略怎么选【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/GitHub_Trending/um/umiMFSU 是 Umi 默认开启的、基于 webpack5 Module Federation 的打包提速方案它把应用源代码的编译和应用依赖的编译分离开把变动较小的依赖构建成一个 Module Federation 的 remote 应用这样热更新时不需要重新编译依赖热更新时间会明显缩短。MFSU 的关键在于如何把应用代码实际用到的依赖分析出来而normal和eager就是两种不同的分析方式直接决定了构建是串行还是并行、冷启动快还是慢。这篇文章基于 MFSU 指南和配置项文档说明两种策略的工作方式、适用场景以及选定策略后如何对照文档判断已知问题。策略配置在哪里改MFSU 默认开启strategy的默认值是normal完整默认值为{ mfName: mf, strategy: normal }。要切换策略在 Umi 配置里修改mfsu.strategy// 使用 normal 策略编译时分析 mfsu: { strategy: normal, }// 使用 eager 策略扫描方式 mfsu: { strategy: eager, }不打算使用 MFSU 时配置mfsu: false关闭即可。参数细节可对照 mfsu 配置项完整的策略说明见 MFSU 指南。normal编译时分析构建过程串行normal 策略的工作方式是先对应用项目源码单独进行编译编译的同时收集项目本身的依赖以及转译过程中由转译器比如 babel插入的新依赖。这些插入的依赖在项目代码层面不可见只有通过转译的插件才能收集到。项目代码编译完成后MFSU 再拿收集到的结果去构建依赖部分的代码。整个流程是串行的先编译项目代码再构建依赖。它的好处是收集到的依赖是完整的项目代码和依赖代码的构建打包完全分离项目代码修改以后只需要构建项目代码部分。缺点就是构建过程串行耗时会叠加。eager静态扫描编译并行eager 策略不做编译时分析它先读取项目中的所有源代码文件通过静态分析获取项目依赖然后拿着这份依赖信息并行进行项目代码的编译和依赖的编译。文档给出的示例数据文档示例非所有项目的固定预期在一个 17 万行代码、1400 多个文件的项目中静态分析一次只需要 700ms 左右。并行的代价是静态分析收集到的依赖会缺失后面项目代码编译时插入的依赖这部分依赖最终会和项目代码一起编译打包。针对这个缺陷配置项提供了include参数它仅在strategy: eager模式下生效用于补偿静态分析无法分析到的依赖// 例如 react 未进入 Module Federation 远端模块时 mfsu: { strategy: eager, include: [react], }按文档的选择依据决定策略MFSU 指南给出了明确的选择建议对应如下项目形态项目情况文档建议不使用 Module Federation 功能项目依赖变动不频繁先尝试 esbuild 构建monorepo 项目使用normal策略推荐同时开启monorepoRedirect配置项目较大项目代码基数较大使用eager策略项目刚刚启动会频繁改动依赖使用eager策略其他类型的项目随意选择其中两点值得展开esbuild 构建MFSU 支持用 Webpack 或 esbuild 构建项目依赖默认是 Webpack。通过mfsu: { esbuild: true }开启后依赖的预编译走 esbuild首次启动更快缺点是二次编译不会有物理缓存稍慢一些所以文档推荐依赖比较稳定的项目使用。monorepo 场景monorepoRedirect会把其他子包的导入重定向到它们的源码位置除了支持热更新、无需预构建子包文档也明确说它可以解决MFSU场景改动子包不热更新的问题。这正是 monorepo 选normal时搭配它的原因参数用法见 monorepoRedirect 配置项。应用策略后如何判断状态和已知问题文档没有给出统一的计时命令来对比两种策略的耗时但可以依据文档描述的行为特征和已知错误现象来判断当前策略是否工作正常。判断 eager 的扫描是否生效文档示例中 eager 的静态分析耗时在千行万行规模的项目里是几百毫秒级上文 700ms 为该文档对应项目的示例值如果扫描明显慢于这个量级说明项目规模或依赖状况不同需要结合下面的错误现象排查。依赖缺失eager 常见出现如下报错时检查对应依赖是否已经安装error - [MFSU][eager] build worker failed AssertionError [ERR_ASSERTION]: filePath not found of lodash.capitalizeReact 多实例问题某些复杂场景下 React 的代码被打包多份运行时产出多个 React 实例并在浏览器报错。解法是通过 Module Federation 的shared配置避免多实例mfsu: { shared: { react: { singleton: true, }, }, }注意如果开启了 MF 插件需要开启shared参考 MF 插件文档。依赖环问题monorepo 中项目依赖 A 包、A 又依赖 monorepo 子包 B 时会形成依赖环或者某个依赖的实现引用了.umi目录下的内容导致开启 MFSU 后不能正常编译。这两种情况都通过mfsu.exclude配置解决mfsu: { exclude: [B], }exclude支持字符串全词匹配或正则。另外如果项目代码需要在 Worker 中使用必须把 Worker 需要的依赖加进exclude——因为 Module Federation 通过window对象共享模块Worker 中无法使用这些模块。externals script 兼容问题如果项目依赖 a、a 依赖 b而 b 配置了 script 类型的 externals开启 MFSU 时import * as b from b拿到的会是PromiseModule而不是正常的 Module 信息文档判断为 webpack 对 externals script 和 Module Federation 兼容处理的问题。解法是不让两者混用只在生产环境开启该 externalsexternals: { ...(process.env.NODE_ENV production ? { b: [script https://cdn/b.js, b] } : {}), }小结选择路径回到项目形态本身依赖稳定的项目按文档建议先试 esbuild 构建monorepo 用normal搭配monorepoRedirect代码基数大的项目和依赖频繁变动的新项目用eager配合include补偿静态分析不到的依赖。选定后文档列出的依赖缺失报错、React 多实例、依赖环和 Worker 限制就是判断策略是否顺畅、以及该用shared、exclude、include中哪一项去修的直接依据。MFSU 缓存默认放在node_modules/.cache/mfsu也可以通过cacheDirectory配置项调整位置便于在排查时定位缓存产物。【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/GitHub_Trending/um/umi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考