build: ERR_REQUIRE_CYCLE_MODULE when loading oxc-parser in StackBlitz / WebContainer

Start by reading the optionalDependencies in the @angular/build package manifest and compare them with the package's Oxc integration. Check how the proposed WASI binding dependency is resolved by oxc-parser in WebContainer. The issue is done when a clean install makes the binding available up front and Angular builds in WebContainer without the runtime download failure.

Command

build, serve

Is this a regression?

Yes, this behavior used to work in the previous version

Description

In StackBlitz (WebContainer), running an Angular application with @angular/build fails during ng serve / ng build with:

(node:12) ExperimentalWarning: WASI is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
[oxc-parser] Downloading @oxc-parser/[email protected] on WebContainer...
Error [ERR_REQUIRE_CYCLE_MODULE]: Cannot require() ES Module /home/projects/stackblitz-starters-ki4mfjac/node_modules/oxc-parser/src-js/index.js in a cycle. (from /home/projects/stackblitz-starters-ki4mfjac/node_modules/@angular/build/src/tools/oxc/oxc-transform.js) A cycle involving require(esm) is not allowed to maintain invariants mandated by the ECMAScript specification. Try making at least part of the dependency in the graph lazily loaded.
    at ModuleLoader.importSyncForRequire (node:internal/modules/esm/loader:169:3960)
    at loadESMFromCJS (node:internal/modules/cjs/loader:160:19002)
    at Module._compile (node:internal/modules/cjs/loader:160:19068)
    at Module._extensions..js (node:internal/modules/cjs/loader:160:20043)
    at Module.load (node:internal/modules/cjs/loader:160:17661)
    at Module._load (node:internal/modules/cjs/loader:160:15179)
    at wrapModuleLoad (node:internal/modules/cjs/loader:160:4199)
    at Module.require (node:internal/modules/cjs/loader:160:17842)
    at require2 (node:internal/modules/helpers:177:3126) {
  code: 'ERR_REQUIRE_CYCLE_MODULE'
}

Parent issue: https://github.com/stackblitz/starters/issues/136

Analysis & Root Cause

1. No actual cyclic dependency in the code:
   The module graph (oxc-transform.ts -> oxc-parser, oxc-transform.ts -> traversal.ts -> oxc-parser) is an acyclic DAG.
   The ERR_REQUIRE_CYCLE_MODULE error is a known misleading error in Node.js's synchronous require(esm) loader (Node.js issues #55516 and #57172). When an ES module throws an error during synchronous require(esm) evaluation, Node's loader frequently shadows the real underlying exception and reports that the module was required in a cycle.

2. WebContainer Fallback Failure:

   • StackBlitz WebContainer cannot run native .node addons.
   • oxc-parser's optionalDependencies only list platform-specific native addons (@oxc-parser/binding-linux-x64-gnu, etc.) and do not list @oxc-parser/binding-wasm32-wasi. Consequently, package managers running in WebContainer never install the WASI binding.
   • At runtime, oxc-parser/src-js/bindings.js detects WebContainer and falls back to webcontainer-fallback.cjs, which attempts to run childProcess.execFileSync("pnpm", ["i", "@oxc-parser/binding-wasm32-wasi@..."], { cwd: "/tmp/..." }).
   • Running this synchronous subprocess from a worker thread inside WebContainer fails (or fails to initialize the multi-threaded WASI runtime), causing the synchronous require(esm) evaluation of oxc-parser to fail and surface as ERR_REQUIRE_CYCLE_MODULE.

Proposed Solution (Option 4A: Add @oxc-parser/binding-wasm32-wasi to @angular/build optionalDependencies)

In oxc-parser/src-js/bindings.js, before falling back to webcontainer-fallback.cjs, it checks:

__napiWasiResolveCandidate('@oxc-parser/binding-wasm32-wasi', true, undefined)

If @oxc-parser/binding-wasm32-wasi is already present in node_modules, oxc-parser directly loads it and bypasses webcontainer-fallback.cjs and the dynamic pnpm i in /tmp entirely.

A viable solution (Option 4A) is to declare @oxc-parser/binding-wasm32-wasi in @angular/build's optionalDependencies (similar to how lmdb is declared).
This ensures that package managers install the WASI binding up-front alongside @angular/build, preventing the runtime dynamic installation and the resulting failure in WebContainer.

Minimal Reproduction

1. Open https://stackblitz.com/edit/stackblitz-starters-ki4mfjac?file=package.json (or update any StackBlitz Angular starter to Angular CLI v22.2+).
2. Run npm install && npm start (or ng serve).
3. Notice the build fails with ERR_REQUIRE_CYCLE_MODULE: Cannot require() ES Module .../oxc-parser/src-js/index.js in a cycle.

Exception or Error

(node:12) ExperimentalWarning: WASI is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
[oxc-parser] Downloading @oxc-parser/[email protected] on WebContainer...
Error [ERR_REQUIRE_CYCLE_MODULE]: Cannot require() ES Module /home/projects/stackblitz-starters-ki4mfjac/node_modules/oxc-parser/src-js/index.js in a cycle. (from /home/projects/stackblitz-starters-ki4mfjac/node_modules/@angular/build/src/tools/oxc/oxc-transform.js) A cycle involving require(esm) is not allowed to maintain invariants mandated by the ECMAScript specification. Try making at least part of the dependency in the graph lazily loaded.
    at ModuleLoader.importSyncForRequire (node:internal/modules/esm/loader:169:3960)
    at loadESMFromCJS (node:internal/modules/cjs/loader:160:19002)
    at Module._compile (node:internal/modules/cjs/loader:160:19068)
    at Module._extensions..js (node:internal/modules/cjs/loader:160:20043)
    at Module.load (node:internal/modules/cjs/loader:160:17661)
    at Module._load (node:internal/modules/cjs/loader:160:15179)
    at wrapModuleLoad (node:internal/modules/cjs/loader:160:4199)
    at Module.require (node:internal/modules/cjs/loader:160:17842)
    at require2 (node:internal/modules/helpers:177:3126) {
  code: 'ERR_REQUIRE_CYCLE_MODULE'
}

Node.js v22.22.3

Your Environment

Angular CLI: 22.2.3
Node: 22.22.3 (WebContainer)
OS: linux x64 (WebContainer)

Anything else relevant?

Parent issue: https://github.com/stackblitz/starters/issues/136