[swc-plugin] Fix Windows WASM plugin linking#2174
Conversation
🦋 Changeset detectedLatest commit: c3845c3 The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types 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 |
📊 Benchmark Results
workflow with no steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 1 step💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) workflow with 10 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 25 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro | Express workflow with 50 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) | Express Promise.all with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro | Express Promise.all with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Promise.all with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) Promise.race with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) Promise.race with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) | Nitro Promise.race with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) | Express workflow with 10 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 25 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 50 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) workflow with 10 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express | Nitro workflow with 25 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) workflow with 50 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) | Nitro Stream Benchmarks (includes TTFB metrics)workflow with stream💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express | Nitro stream pipeline with 5 transform steps (1MB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) 10 parallel streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express fan-out fan-in 10 streams (1MB each)💻 Local Development
▲ Production (Vercel)
SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
Check the workflow run for details. |
🧪 E2E Test Results✅ All tests passed Summary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
|
karthikscale3
left a comment
There was a problem hiding this comment.
Approve. ✅ Minimal, well-scoped, correctly targeted, and empirically verified.
Verification
- Target is correct.
build.jsrunscargo build-wasm32 --release→wasm32-unknown-unknown, which is exactly the section the flag is added to. The unusedbuild-wasip1alias is irrelevant here. - It fixes the reported failure. On this PR
Unit Tests (windows-latest)passes (8m24s) andE2E Windows Testspasses (19m17s). The only red checks areBenchmark Community World(Redis, Redis+BullMQ, MongoDB) — unrelated benchmark/infra jobs, two of which ran a full hour before failing (timeouts, not linkage). - TOML/cargo syntax is valid and correctly placed for per-target rustflags; the empty changeset (
---\n---) is exactly whatpnpm changeset --emptyemits to pass the gate without a release.
Non-blocking notes
--allow-undefinedis broad — it lets all undefined symbols become wasm imports, not just SWC's three host functions, so a future genuinely-missing symbol would fail at plugin-load instead of build time. Tighter options are--import-undefinedor--allow-undefined-file=<allowlist>, but--allow-undefinedis the conventional choice in the SWC plugin ecosystem.- Applies on all platforms, which is preferable — consistent build behavior, and the imports are host-provided everywhere.
RUSTFLAGSprecedence caveat:target.<triple>.rustflagsin.cargo/config.tomlis ignored if a globalRUSTFLAGSenv var is set (env wins, no merge). Worth a quick confirm CI doesn't export one for the plugin build — the green Windows run suggests it's fine today.
Nice touch documenting the why in the comment for a non-obvious linker flag. The failing benchmark checks are unrelated and shouldn't gate this.
Signed-off-by: Peter Wielander <mittgfu@gmail.com>
|
Backport PR opened against |
Context
PR #2169 failed Windows unit tests while building
@workflow/swc-pluginwithrust-lldundefined symbols for SWC host imports such as__emit_diagnostics,__set_transform_result, and__get_transform_context