webpack中multi-compiler与multiple-entry-points的区别及多页配置相关问题

Q1：在多HTML页面配置场景下，multi-compiler和multiple-entry-points各自有什么优缺点？是否multi-compiler配置灵活性更高但构建速度更慢？ #

• multiple-entry-points（单编译器多入口）
  优点：
  • 构建速度快：所有入口共享同一编译进程、缓存和模块依赖图，公共依赖仅编译一次，增量编译优势尤其突出
  • 维护成本低：仅需维护一份基础配置，入口单独做列表配置即可，公共规则、插件无需重复编写
  • 公共依赖拆分便捷：可直接通过splitChunks抽离多页面共用依赖，降低整体打包体积
    缺点：
  • 灵活性有限：所有入口必须遵循同一套编译规则，无法为单个页面配置不同的loader/plugin规则、或不同版本的webpack生态工具，也不能单独控制某一页面的编译时机
  • 耦合度高：单个页面的编译错误会阻塞全项目构建，单实例内存占用会随入口数量上涨持续升高
• multi-compiler（多编译器实例）
  优点：
  • 灵活性极强：每个编译器实例完全独立，可给不同页面配置完全不同的编译规则，单个页面编译失败不会影响其他实例构建
  • 隔离性强：各页面编译上下文完全独立，不会出现不同页面的变量、chunk互相干扰的问题，适合页面差异极大的项目
    缺点：
  • 构建速度慢：每个实例都会走完整编译流程，公共依赖会被重复编译，无共享缓存，全量构建速度随入口数量线性下降
  • 维护成本高：每份实例都需单独配置，公共逻辑需要自行抽离复用，splitChunks仅能在单个实例内部生效，跨实例公共依赖无法统一拆分

你提到的“multi-compiler配置灵活性更高但构建速度更慢”结论完全成立，常规多页项目优先选择多入口方案即可，仅当页面有定制化编译需求时再考虑多编译器方案。

Q2：如果使用multiple-entry-point配置，如何在plugin或loader中获取当前的entry名称？loader层面无法实现该需求，那么plugin层面是否可以实现？ #

loader层面确实无法直接拿到对应entry名称，因为loader是针对单个模块执行的，一个模块可能被多个entry同时依赖，本身不存在唯一对应的entry。
plugin层面完全可以实现，对应方法如下：

• 编译开始阶段获取全量entry配置：监听compiler.hooks.entryOption钩子，回调参数可直接拿到完整entry配置对象，遍历即可获得所有entry的名称和对应入口文件路径
• 获取单个模块所属的entry列表：在compilation.hooks.finishModules钩子触发后，遍历compilation.entries，递归遍历每个entry的模块依赖，给对应模块打上所属entry的标记，后续其他钩子处理模块时就可以读取到对应的entry名称
• 配合html-webpack-plugin获取单个HTML对应的entry：监听htmlWebpackPluginBeforeHtmlProcessing钩子，回调参数中的plugin.options.chunks就是当前HTML对应的entry名称列表

Q3：有没有办法获取从entry出发的完整依赖图？类似webpack-bundle-analyzer的功能。 #

可以直接通过webpack暴露的原生接口获取完整依赖图，无需依赖额外工具：
编译完成后在compiler.hooks.done钩子中拿到compilation实例，其中compilation.moduleGraph存储了完整的模块依赖关系，compilation.entrypoints存储了所有入口对应的chunk链，遍历这两个对象就能拿到从入口出发的所有依赖路径、模块大小、依赖类型等全量信息。
如果仅需要可视化查看依赖结构，直接使用webpack-bundle-analyzer插件即可，它本身就是读取上述compilation数据生成的可视化图，支持按入口筛选查看对应依赖结构，完全匹配需求。

内容的提问来源于stack exchange，提问作者bigboss