webpack ESM 库产物把 export 包在 IIFE，显式开启模块输出

webpack 构建 ESM 库时，生成文件里已有 export，却仍被包在 (() => { ... })() 内，可能随后出现压缩器无法解析或模块加载失败。先检查 library.type 与模块输出设置是否一致；给业务文件再补一个导出语句无法改变外层包装。

这条具体报告来自移除 experiments.outputModule 标记后的 main 构建。其环境输出标成 webpack 5.110.3，但实际使用的是相应 main 提交，不能因此认定所有正式 5.110.3 都经过同一变更。触发方式是在普通 web 或 node 目标下声明 library.type: 'module'，却未显式开启 output.module。

受影响的默认解析没有从库类型推出模块输出，仍令 output.module 为 false、output.iife 为 true。库导出插件则按 ESM 库生成 export，两个阶段的判断不一致，最终把只能位于模块顶层的语句放进函数体。

对于确实要发布 ESM 的库，可把两项关系写清楚：

module.exports = {
  target: 'web',
  entry: './src/index.js',
  output: {
    filename: 'library.mjs',
    library: { type: 'module' },
    module: true,
    iife: false,
  },
};

将它合并到原来的输出配置，保留输出目录、公共路径与其他必要设置。若库类型写在某个 entry 的描述对象上，也要核对最终输出。不要把面向普通 script 的 UMD 库和 ESM 库随意拼在同一输出配置里；需要多种格式时，分别安排对应构建与加载方式。

webpack 5.111.1 的正式默认解析会汇总输出、启用列表与入口声明的库类型；发现 module 或 modern-module 时开启模块输出。这个版本按模块库类型开启模块输出，不应依赖冲突设置必然抛错的行为。可在分支中固定该版本，避免仍使用触发报告的 main 构建：

npm install -D webpack@5.111.1
npm ls webpack
npm run build

旧版本若仍把模块输出放在实验开关后面，应按那个版本的配置契约处理，不能机械删除实验项后继续使用旧二进制。升级还需核对项目 loader 和插件支持范围。

验收分开发与生产两种构建。查看生成文件：ESM export 应位于模块顶层，不能只因为文本里能搜到 export 就认为正确。再按库的真实消费方式导入它，例如从使用 type="module" 的页面或项目已有 ESM 消费测试导入一个实际导出，并调用它。生产压缩构建同样应通过。

如果顶层结构已经正确，但消费端报 CommonJS 与 ESM 互操作错误、文件扩展名错误或缺少某个导出，应继续检查包的 exports、消费入口及输出内容。这里处理的是 webpack 输出默认值与库类型不一致造成的非法包装，不是所有模块互操作问题。