Why does Webpack emit importScripts() for ES‑module Web Workers, causing runtime failure?

[kousik2000]

We are migrating an Angular application from the default Angular CLI builder (@angular-devkit/build-angular) to ngx-build-plus to enable custom webpack configuration / Module Federation.
While doing so, we ran into a consistent runtime error in ES‑module Web Workers that does not occur when using the default Angular DevKit builder.

Uncaught TypeError: Failed to execute 'importScripts' on 'WorkerGlobalScope': Module scripts don't support importScripts(). at __webpack_require__.f.i (importScripts chunk loading:26:1) at ensure chunk:6:1 at Array.reduce (<anonymous>) at __webpack_require__.e (ensure chunk:5:1) at Array.map (<anonymous>) at __webpack_require__.x (startup chunk dependencies:3:1) at startup:3:1

Environment

"@angular/cdk": "^20.2.9", "@angular/common": "^20.1.0", "@angular/compiler": "^20.1.0", "@angular/core": "^20.1.0", "@angular/forms": "^20.1.0", "@angular-architects/module-federation": "^20.0.0", "@angular-architects/module-federation-runtime": "^19.0.1", "@angular-architects/module-federation-tools": "^19.0.1", "ngx-build-plus": "^20.0.0",

Code
`# worker listener
const worker = new Worker(new URL('./model.worker.ts', import.meta.url));

#worker.ts
const parserClass = new ModelParserClass();
addEventListener('message', ({ data }) => {
#code using parser class
})

#parser class
below are my parser class imports

import { UtilFunctions } from 'my-angular-shared-library';
import { cloneDeep } from 'lodash';
import { RailLive } from '@interfaces/common.interfaces';`

Any guidance, recommended configuration, or confirmation of best practices for using ES‑module Web Workers (especially with code splitting or Module Federation) would be greatly appreciated.

Thanks for your time and for the work you do on Webpack.

[alexander-akait]

Looks like you have type="module", but build your code for non ECMA modules, so webpack generates importScripts, you need to set output.module or remove type="module", I can't say why it happens because no reproducible test repo or other additional information, if you provide more details (or reproducible test repo) I will investigate and say where to fix it, let's move to discussion right now, anyway feel free to provide more details and we will help

[kousik2000]

Thanks for the response and for taking a look into this.

From further debugging, it looks like the issue appears only when ES‑module workers end up with runtime chunk loading (via  importScripts ), which happens when certain dependencies are actually used in the worker (for example, shared interfaces or utilities that indirectly depend on Angular libraries). Unused imports get tree‑shaken, so the worker works until those code paths are reached.

I’ll try to create a minimal reproducible sample repository on GitHub that demonstrates this behavior clearly and share it here once it’s ready.

[kousik2000]

Thanks for your earlier response. I’ve created a minimal reproducible repository to better illustrate the issue:

Repo: https://github.com/kousik2000/mfe-worker-repo

What the repo shows

• Using the default Angular builder (Angular CLI), the Web Worker works correctly.
• After switching to ngx-build-plus with Webpack Module Federation, the same worker setup fails at runtime.

Errors observed

Depending on configuration, I consistently hit one of the following:

• Failed to execute 'importScripts'... Module scripts don't support importScripts()
• Cannot find module 'xxx'
• Unsatisfied version ... shared singleton module

Key observations

• The issue only appears when the worker includes code paths that pull in dependencies (e.g., parser → shared library → Angular-related code).

• If those imports are removed or not used, the worker works (tree-shaking avoids the problem).

• It seems that:

  • Webpack generates chunk loading via importScripts
  • The worker is treated as an ES module
  • This mismatch causes runtime failure

• Additionally, when using Module Federation:

  • Shared dependencies are not bundled into the worker
  • The worker attempts to resolve them at runtime
  • But the federation runtime is not available in the worker context

---

Questions

1. Is this expected behavior?
   Should Web Workers be treated as completely isolated bundles when using Module Federation (i.e., no shared dependencies)?

2. Worker + Module Federation support
   Is there any recommended or supported way to use shared modules inside a Web Worker, or is it fundamentally unsupported due to the missing runtime?

3. Chunk loading strategy
   When dependencies are introduced, webpack splits the worker into chunks and uses importScripts.

   • Is there a recommended way to force a worker to remain a single bundle?
   • Or to make chunk loading compatible with module workers?

4. Best practice going forward
   From your perspective, what is the correct pattern?

   • Avoid shared dependencies in workers entirely?
   • Maintain a separate “worker-safe” subset of libraries?
   • Or configure webpack differently?

---

Overall, I want to confirm whether this is:

• an expected limitation of current webpack + Module Federation behavior, or
• something that could be improved or better documented