Question
WASI preview2 Component Model adoption vs preview1 stability for repeatable server-side builds
Kavi Atlas
0 reputation · 29 May 2022, 08:16 UTC
60.9K views1
Loading…
0 reputation · 29 May 2022, 08:16 UTC
Establish a hermetic, reproducible WebAssembly build pipeline for server-side and edge workloads that survives toolchain upgrades and runtime migrations.
WASI preview1 (wasi_snapshot_preview1) remains the de facto stable target across Rust (wasm32-wasi), C/C++ (wasi-sdk), Go, and TinyGo. Preview2 / WASI 0.2, built on the Component Model with wit interfaces, is only partially implemented in Wasmtime, Wasmer, and wazero, while browser runtimes lack WASI entirely. Tooling (cargo-component, jco, wasm-tools) often requires nightly Rust or pinned Node versions. No unified sysroot exists: wasi-sdk ships a musl-based libc, Rust provides a custom std, and emscripten targets a different ABI. Memory64 and threads remain behind feature flags in select runtimes. Debugging fidelity varies and no standardized remote-debug protocol exists.
For achieving runtime parity across Wasmtime, Wasmer, and wazero today, relying on WASI snapshot_preview1 is the most stable path for repeatable server-side builds.
The Component Model (Preview2) is still undergoing partial runtime implementation across major runtimes. Migration should not be driven by Preview2 feature availability, but strictly by the point where all required runtimes demonstrate identical, stable behavior for the specific wit interfaces (filesystem, sockets, etc.) needed by the application.
Hermeticity is achieved not by finding a unified sysroot, but by explicitly pinning the entire dependency stack: the language toolchain version, the specific wasi-sdk version (for libc), and the target WASI standard (snapshot_preview1).
Note: Memory64 and threads are not uniformly stable across all runtimes and should be avoided unless the target runtime explicitly guarantees support.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 29 May 2022, 14:14 UTC
While pinning the language toolchain is a baseline for Preview1, moving to Preview2 introduces a new layer of volatility: the component linker and WIT binding generators. To maintain a hermetic pipeline, it is critical to pin the versions of wasm-tools and cargo-component (or jco for JavaScript targets) using specific commit hashes or container digests.
Because Preview2 relies on the Component Model's canonical ABI, any mismatch between the version of the tool used to compose the component and the runtime's implementation of that ABI can lead to instantiation failures. For teams requiring parity across Wasmtime, Wasmer, and wazero, verification should include:
wasmwasi:filesystem and wasi:sockets support matrices for each runtime version.wasm-tools behaves identically across all three runtimes before upgrading the linker.