WASI commands

With platform: 'wasi' there is no JavaScript host at all. Your C++ becomes one wasm32-wasip3 command component that runs under any WASI 0.3 runtime with Wasm 3.0 exception support - wasmtime 47 and newer. No glue, no loader, no initNative.

Build a command

Provide a main(int, char**) in src/native and build with -p wasi. The output is a single .wasm file:

There is nothing to configure to get started: with no local wasi-sdk, the build runs inside the Docker image, which ships one. For native-speed builds, point at a local sdk (34 or newer, with the wasm32-wasip3 sysroot):

Files and network

Data files declared by your dependency graph land in a real dist/data/ folder, which you preopen with --dir. Sockets work through wasi:sockets when the runtime grants them:

This is the same data / env declaration described in Assets; on WASI it doubles as the runtime contract - directories become preopens, env becomes the guest environment.

Prebuilt -wasi libraries

Library packages ship a dedicated WASI variant next to their -wasm, -android and -ios siblings. Depend on @cpp.js/package-<name>-wasi when you target WASI; recipes, patches and data travel inside the package.

CLI tools from npm

Where an upstream project ships command-line tools, a -bin-wasi package publishes them prebuilt. Install and run - no compiler involved, only wasmtime on your PATH:

Every tool is exposed as <tool>-wasi, so a native install of the same tool is never shadowed. The launcher resolves mounts and guest environment from the package itself - the gdal family mounts its GDAL_DATA and PROJ_DATA folders, openssl provides the CA bundle for https. Tools that are mapped but not published print the exact from-source build command rather than failing silently.

Limits

• No processes and no dynamic loading.
• Single-threaded for now.
• Rust is skipped on this platform - there is no wasm32-wasip3 Rust target yet.
• Anything unsupported fails cleanly at runtime instead of trapping at instantiation.