fix(oxc): fall back to wasm

[avivkeller]

As titled

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
api-docs-tooling	Error		Jul 19, 2026 6:59pm

[cursor]

PR Summary

Low Risk
Dependency-only change for build-time parsing; no application logic edits, with minor version skew between oxc-parser 0.139 and the WASM binding 0.140.

Overview
Ensures doc-kit can parse JS/TS via OXC on platforms that lack a matching native @oxc-parser/binding-* package by declaring @oxc-parser/binding-wasm32-wasi (^0.140.0) as a regular dependency instead of relying only on oxc-parser’s optional WASM optionalDependency.

The lockfile reflects that shift: WASM-related packages are no longer marked optional at the root install graph, while oxc-parser itself stays on ^0.139.0. A changeset records a patch release noting the WASM fallback behavior.

^{Reviewed by Cursor Bugbot for commit 8fed169. Bugbot is set up for automated code reviews on this repo. Configure here.}

[codecov]

⚠️ JUnit XML file not found

The CLI was unable to find any JUnit XML files to upload.
For more help, visit our troubleshooting guide.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8fed169. Configure here.}

[cursor]

WASM binding version mismatch

High Severity

The new direct dependency on @oxc-parser/binding-wasm32-wasi is pinned to ^0.140.0 while oxc-parser remains at ^0.139.0. OXC expects parser and platform bindings to share the same release. When the optional nested 0.139.0 WASM package is not installed, Node resolves the hoisted 0.140.0 binding for a 0.139.0 parser—the exact fallback path this change targets.

 

^{Reviewed by Cursor Bugbot for commit 8fed169. Configure here.}

[avivkeller]

cc @Boshen howdy from Node.js! Any idea on how to allow a WASM fallback without npm throwing invalid architecture errors?

[avivkeller]

In the meantime, I'm going to swap us for a WASM parser like swc or yuku

[AugustinMauroy]

https://stackblitz.com/edit/oxc-parser?file=package.json
https://npmx.dev/package-code/oxc-parser/v/0.140.0/src-js%2Fwasm.js

miss click and I cannot discard my approval

[Boshen]

cc @Boshen howdy from Node.js! Any idea on how to allow a WASM fallback without npm throwing invalid architecture errors?

@oxc-parser/binding-wasm32-wasi sets cpu to wasm32 so adding it as a dependency fails. Should it be optionalDependency?

[avivkeller]

That wouldn't help, would it? Our consumer (node core) runs npm ci, so it wouldn't install it if it were an optionalDependency

[Boshen]

Wait ... why do you need this fallback when oxc-parser provides @oxc-parser/binding-wasm32-wasi as an optionalDependencies (along with all other builds).

Which architecture are we missing, I can add those instead.

[avivkeller]

Wait ... why do you need this fallback when oxc-parser provides @oxc-parser/binding-wasm32-wasi as an optionalDependencies (along with all other builds).

I assumed (possibly incorrectly) that by manually installing the WASM binding, oxc would 'fall back' to it if no bindings were found.

Which architecture are we missing, I can add those instead.

Thank you, that would be great (if it's not too much work, of course)!

In our CI, the following runners failed:

• smartos23-x64 (I'm guessing this is smartos and x64 for os and arch, respectively)
• aix72-power9 (I'm guessing this is aix and ppc64 for os and arch, respectively)
• aix73-power9 (I'm guessing this is aix and ppc64 for os and arch, respectively)

If this is too difficult, we can also throw an error that doc generation is not available on these machines (cc @nodejs/web-infra wdyt?). Although, adding these architectures would allow us to use