feat(bindings/node): publish @swc/core-wasm32-wasi (napi-rs wasi build) - #12064
Conversation
binding.js (generated by napi-rs) already probes for @swc/core-wasm32-wasi
as its wasi fallback, but the package was never built or published, so
require('@swc/core') throws 'Failed to load native binding' on every
wasm32-wasi runtime. binding_core_node compiles for wasm32-wasip1-threads
with no source changes when the plugin feature (wasmer, which cannot run
inside a wasm module) is disabled, matching the plugin-less targets that
already build with --no-default-features --features swc_v1.
- add wasm32-wasip1-threads to packages/core napi.targets so
napi artifacts / napi prepublish pick up the new package
- add packages/core/scripts/npm/wasm32-wasi (package.json + README),
mirroring the other per-target npm dirs
- add a publish matrix entry building the target for @swc/core only,
and include the napi-generated wasi-worker files in the artifact upload
🦋 Changeset detectedLatest commit: 6d82653 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
|
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6bd2a545df
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "Codex (@codex) review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "Codex (@codex) address that feedback".
| "dependencies": { | ||
| "@napi-rs/wasm-runtime": "^1.1.6" | ||
| } |
There was a problem hiding this comment.
Adding this package under packages/core/scripts/npm/* makes it a workspace importer, and it also introduces @napi-rs/wasm-runtime@^1.1.6, but pnpm-lock.yaml was not updated: the lockfile still lists the existing core npm subpackages and has no packages/core/scripts/npm/wasm32-wasi importer. The release workflow runs pnpm install --frozen-lockfile before building/publishing, so any release tag containing this new package.json will fail during install until the lockfile includes this workspace and dependency resolution.
Useful? React with 👍 / 👎.
Merging this PR will improve performance by 3.18%
Performance Changes
Tip Curious why this is faster? Comment Comparing 
Footnotes
|
The new packages/core/scripts/npm/wasm32-wasi dir is a workspace importer (the scripts/npm/* glob) and adds @napi-rs/wasm-runtime, so the release workflow's pnpm install --frozen-lockfile needs the lockfile to know both. Regenerated with the pinned pnpm (10.33.3) via install --lockfile-only; the @emnapi/core peer-suffix churn on @napi-rs/cli comes from @napi-rs/wasm-runtime entering the graph, and the @swc/core peer-context bumps are the lockfile catching up to the current workspace versions.
2 participants
The napi-rs loader in
packages/core/binding.jsalready triesrequire('@swc/core-wasm32-wasi')as its last fallback, but that package has never actually been built or published. So on any wasm32 runtime,require('@swc/core')just dies withFailed to load native bindingbefore the@swc/wasmfallback in index.js ever gets a chance to run.This matters for in-browser Node runtimes like WebContainers and Strapkit, where everything runs on wasm32-wasi and there is no native binary to load. In practice anything that pulls in
@swc/core—@swc/clibuilds (swc src -d dist),@swc/jest, webpack'sswc-loader,@vitejs/plugin-react-swc— is currently broken in those environments, and each runtime ends up carrying its own workaround. rolldown, oxc and rspack all publish a wasi binding through the same napi-rs pipeline, so swc is really the odd one out here.What this PR does:
wasm32-wasip1-threadstonapi.targetsinpackages/core/package.json, sonapi artifactspicks up the wasi files andnapi prepublishadds@swc/core-wasm32-wasito optionalDependencies (cpu: ["wasm32"]keeps it off native installs)packages/core/scripts/npm/wasm32-wasi/mirroring the other per-target npm dirspublish-npm-package.yml. It only builds for@swc/core(the other packages skip it and the artifact upload tolerates that), and the upload glob now also grabs the napi-generatedwasi-worker*files. I skipped theswcCLI binary for this target on purpose — a wasi CLI build is a separate discussion.