Angular使用Webpack5 Module Federation时如何暴露远程端的Web Worker

方案1：固定远程应用的publicPath并配置CORS（推荐生产环境使用） #

这是最稳妥的方案，不需要修改业务代码，仅需调整构建配置即可解决问题：

1. 修改远程应用的webpack.config.js，将output.publicPath从auto改为远程应用的实际部署地址，开发环境填http://localhost:4250/，生产环境替换为对应的线上部署域名：

// REMOTE webpack.config.js
module.exports = {
  output: {
    uniqueName: "interviews",
    publicPath: "http://localhost:4250/", // 生产环境替换为实际部署地址
  },
  // 其余配置保持不变
}

2. 给远程应用的静态资源服务配置CORS，允许主应用域名（开发环境为http://localhost:5000）访问静态资源。开发环境可以直接在远程应用的angular.json中给devServer添加CORS配置：

// 远程应用的angular.json
{
  "projects": {
    "interviews": {
      "architect": {
        "serve": {
          "options": {
            "cors": true
          }
        }
      }
    }
  }
}

• 优点：无业务侵入，worker可以正常拆分为独立bundle，不会增加远程模块的加载体积，适合worker体积较大的场景
• 缺点：需要额外配置CORS规则，生产环境需要提前确定远程应用的部署域名

方案2：内联worker代码到远程模块bundle（适合worker体积较小的场景） #

通过webpack的magic comment让worker代码直接内联到调用它的远程模块bundle中，不会生成独立的worker文件，从根源避免跨域问题：
修改远程应用中实例化Worker的代码，添加内联的magic comment即可：

const myWorker = new Worker(
  /* webpackInline: true */ 
  new URL('../path/to/workers/worker.ts', import.meta.url),
  { type: 'module', name: 'my-worker' }
);
this.worker = this.createWrapper<WorkerService>(myWorker);

• 优点：无需修改构建配置，无需配置CORS，改造成本极低
• 缺点：worker代码不会被拆分，会增加远程模块的初始加载体积，worker体积超过100KB时不推荐使用

方案3：主应用配置反向代理（适合开发环境临时使用） #

在主应用的开发服务中配置代理，将worker文件的请求转发到远程应用地址，规避跨域限制：

1. 修改主应用的angular.json，给devServer添加proxy规则：

// 主应用的angular.json
{
  "projects": {
    "portal": {
      "architect": {
        "serve": {
          "options": {
            "proxyConfig": "proxy.conf.js"
          }
        }
      }
    }
  }
}

2. 新建proxy.conf.js配置文件：

module.exports = {
  // 如果有多个worker，可以用通配符匹配
  '/*-worker.js': {
    target: 'http://localhost:4250',
    secure: false
  }
}

• 优点：不需要修改远程应用的任何代码和配置
• 缺点：仅适合开发环境使用，生产环境需要额外配置nginx等反向代理规则，维护成本较高

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