Repository navigation
fix(@angular/build): include the oxc-parser WASI binding as an optional dependency - #34540
Merged
Merged
Conversation
…al dependency When running inside a WebContainer environment, such as StackBlitz or the angular.dev playground, native Node.js addons cannot be loaded. The `oxc-parser` package only lists its platform-specific native bindings as optional dependencies and does not include the WebAssembly-based `@oxc-parser/binding-wasm32-wasi` binding. As a result, package managers never install the WASI binding and `oxc-parser` falls back to downloading it on demand at runtime by shelling out to `pnpm` inside a temporary directory. This fallback is executed synchronously while the module graph is being evaluated, from within a worker thread, and via a synchronous `require()` of an ES module. Any failure along that path surfaces as a misleading `ERR_REQUIRE_CYCLE_MODULE` error rather than the underlying cause, which breaks `ng serve` and `ng build` entirely. The binding loader generated by napi-rs checks whether the WASI binding is already resolvable from `node_modules` before attempting the on-demand download. Declaring `@oxc-parser/binding-wasm32-wasi` as an optional dependency of `@angular/build` ensures that package managers install it alongside the package up front. This allows `oxc-parser` to load the WASI binding directly in WebContainer environments and avoids the fragile runtime installation path. The version is pinned to match `oxc-parser` exactly, since the loader rejects bindings whose version does not match the version of the main package. The two dependencies must therefore be kept in lockstep when updating. This mirrors the existing approach used for `lmdb`, which is also declared as an optional dependency to avoid hard failures on platforms where it is unavailable. Note that at the time of this change, the currently published WASI bindings for `oxc-parser` depend on an `@napi-rs/wasm-runtime` version range that resolves to a release incompatible with the `@emnapi` alpha runtime those bindings were built against. Until a compatible `oxc-parser` release is available, the pre-installed binding will fail to initialize in the same way the on-demand download does. This change is nonetheless a prerequisite for a durable fix and will take effect once `oxc-parser` is updated to a release with compatible WASI bindings. Related to angular#34524
clydin
added
target: minor
alan-agius4
approved these changes
Oct 27, 2026
clydin
marked this pull request as ready for review
October 27, 2026 15:03
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Collaborator
|
This PR was merged into the repository. The changes were merged into the following branches:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When running inside a WebContainer environment, such as StackBlitz or the angular.dev playground, native Node.js addons cannot be loaded. The
oxc-parserpackage only lists its platform-specific native bindings as optional dependencies and does not include the WebAssembly-based@oxc-parser/binding-wasm32-wasibinding. As a result, package managers never install the WASI binding andoxc-parserfalls back to downloading it on demand at runtime by shelling out topnpminside a temporary directory. This fallback is executed synchronously while the module graph is being evaluated, from within a worker thread, and via a synchronousrequire()of an ES module. Any failure along that path surfaces as a misleadingERR_REQUIRE_CYCLE_MODULEerror rather than the underlying cause, which breaksng serveandng buildentirely.The binding loader generated by napi-rs checks whether the WASI binding is already resolvable from
node_modulesbefore attempting the on-demand download. Declaring@oxc-parser/binding-wasm32-wasias an optional dependency of@angular/buildensures that package managers install it alongside the package up front. This allowsoxc-parserto load the WASI binding directly in WebContainer environments and avoids the fragile runtime installation path. The version is pinned to matchoxc-parserexactly, since the loader rejects bindings whose version does not match the version of the main package. The two dependencies must therefore be kept in lockstep when updating.Note that at the time of this change, the currently published WASI bindings for
oxc-parserdepend on an@napi-rs/wasm-runtimeversion range that resolves to a release incompatible with the@emnapialpha runtime those bindings were built against. Until a compatibleoxc-parserrelease is available, the pre-installed binding will fail to initialize in the same way the on-demand download does. This change is nonetheless a prerequisite for a durable fix and will take effect onceoxc-parseris updated to a release with compatible WASI bindings.Related to #34524