Angular6迁移Webpack4配置SplitChunksPlugin后运行报错求助

问题拆解 #

我完全懂你现在的头疼——迁移Webpack后，要么生成一堆冗余bundle但应用正常，要么得到想要的3个干净bundle却触发DI解析错误。这个问题本质是Webpack的chunk拆分策略破坏了Angular依赖注入（DI）所需的元数据关联，结合你提到的ModuleConcatenation bailout提示，咱们一步步来修复：

核心原因 #

当你用enforce: true强制把所有node_modules模块塞进vendor，同时拆分polyfills时，可能把Angular核心的DI元数据处理模块（比如@angular/core里的装饰器解析代码）和你的组件代码拆到了完全隔离的chunk里。另外，Webpack 4的模块拼接优化（Module Concatenation）被意外禁用，导致Angular无法正确识别组件的依赖参数。

之前默认的splitChunks: { chunks: 'all' }之所以正常，是因为Webpack自动把和main入口强关联的第三方模块拆成vendors~main，这种拆分保留了Angular核心模块和组件代码的元数据关联，没破坏DI逻辑。

修复方案：调整splitChunks配置 #

试试这个优化配置，它既能生成你想要的3个主bundle，又能保留DI所需的元数据关联：

const optimization = {
  splitChunks: {
    chunks: 'all',
    cacheGroups: {
      // 优先拆分polyfills相关依赖，确保独立成包
      polyfills: {
        name: 'polyfills',
        test: /polyfills|core-js|zone\.js/, // 更精准匹配polyfills模块
        chunks: 'initial', // 只处理入口的初始依赖，避免拆分异步模块
        priority: 10, // 最高优先级，确保被优先匹配
        enforce: true
      },
      // 处理剩下的node_modules依赖，排除已经被polyfills处理的模块
      vendor: {
        name: 'vendor',
        test: /node_modules/,
        chunks: 'initial',
        priority: 5,
        enforce: true,
        exclude: /polyfills|core-js|zone\.js/
      },
      // 保留默认组处理共享模块，避免意外的拆分问题
      default: {
        minChunks: 2,
        priority: -20,
        reuseExistingChunk: true
      }
    }
  },
  // 保留runtime chunk（Webpack 4默认生成），它负责模块加载的关联逻辑，对DI很重要
  runtimeChunk: 'single'
};

额外的关键检查点 #

1. 确保ModuleConcatenationPlugin正常工作：
   生产模式下Webpack 4默认启用这个插件，但开发模式下你可能需要手动加进去，它能把相关模块合并到同一个作用域，帮助Angular保留DI元数据：

   plugins: [
     new webpack.optimize.ModuleConcatenationPlugin()
   ]
   

2. 检查TypeScript配置：
   打开tsconfig.json，确保这两个选项是true——这是Angular生成DI元数据的基础：

   {
     "compilerOptions": {
       "experimentalDecorators": true,
       "emitDecoratorMetadata": true
     }
   }
   

3. 确认组件装饰器完整：
   检查你的IntroComponent，确保它的依赖都正确用@Inject()标注（如果是非类类型依赖），或者类本身有@Injectable()装饰器，没有遗漏元数据。

最后验证 #

应用配置后，你会得到polyfills.js、vendor.js、main.js和一个小型的runtime.js（如果不需要runtime chunk，可以设runtimeChunk: false，但不建议，它能避免缓存失效问题）。运行应用后，那个DI错误应该就消失了。

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