Support for NAPI-RS based native Node.js addons (Qwik, and other framework compilers)

[thejackshelton]

Many modern frameworks use Rust-based compilers that are exposed to Node.js via NAPI-RS.
These ship as native .node addons rather than pure JavaScript, which means they won't
work in a browser-based runtime without special handling.

Example: Qwik

The Qwik optimizer is a Rust-based SWC transform (swc_ecmascript) exposed to Node.js via
NAPI-RS (napi = "2"). It runs as a Vite plugin during development and build. Without
native addon support, Qwik projects cannot run in Nodepod.

• Rust optimizer source: packages/qwik/src/optimizer/core/ in QwikDev/qwik
• NAPI bindings: packages/qwik/src/napi/

Other affected tools:

• oxc-parser — Used in the Vite/Rolldown ecosystem, also Rust + NAPI-RS
• Other frameworks with Rust-based compilers exposed via NAPI-RS (this pattern is
  becoming increasingly common)

Context:

Nodepod already handles replacing Rolldown with Rollup (since Rolldown is Rust-based),
but NAPI-RS addons are a broader pattern across the Vite ecosystem. Most Vite-based
framework projects depend on at least one NAPI-RS module.

Possible approaches:

• WASM builds of the native addons (some projects may publish WASM variants)
• Auto-detection and substitution of NAPI modules with WASM equivalents where available
• A polyfill/shim layer for the NAPI-RS runtime

[R1ck404]

Thanks for the detailed write-up. This is largely addressed by the WASI preview1 polyfill and native-to-WASM fallback chain shipped in v1.0.4 (#7).

Most mature NAPI-RS packages (SWC, oxc-parser, etc.) already include built-in fallback logic, they attempt to load the native .node addon, and when that fails, they automatically fall back to a bundled WASM variant. Since Nodepod now provides a full WASI preview1 implementation, these WASM fallbacks should work without any additional configuration.

As a concrete example, Qwik projects are already functional in Nodepod, we're able to run Qwik through both Vite and QwikCity in development mode, since Qwik's optimizer is built on SWC which ships WASM builds that the fallback mechanism picks up automatically. Production builds haven't been fully tested yet, but dev workflows work as expected.

For packages that don't include an automatic fallback, Nodepod's native-to-WASM fallback chain will attempt to resolve a WASM alternative before erroring out. Some packages like sharp will fail on initial load but provide a helpful error message pointing to the correct WASM variant to install, after installing that, it works as expected.

For packages that don't ship a WASM variant at all, there's not much we can do on our end since the underlying native binary simply can't execute in a browser environment. However, these cases are becoming increasingly rare as most major tools in the ecosystem now publish WASM builds.

Note: For the best experience, we recommend using a Chromium-based browser. Firefox has a known limitation where some error messages from native addon load failures may appear as undefined, making it harder to identify which WASM variant to install as a replacement.