wasm32-wasip2 Support: Journey, Challenges, and Solutions #1
Description
wasm32-wasip2 Support: Journey, Challenges, and Solutions
This issue documents our comprehensive investigation and implementation to get WAC working with the wasm32-wasip2 target on stable Rust.
🎯 Final Result
✅ Successfully built WAC for wasm32-wasip2 (110MB binary)
✅ Stable Rust only - no nightly required
✅ Core functionality working - parse, compose, targets commands
🔍 Key Issues Discovered & Solutions
1. tempfile crate - unstable wasip2 features
Problem: tempfile 3.21.0 used std::os::wasi::io traits requiring unstable wasip2 features
use std::os::wasi::io::{AsFd, AsRawFd, BorrowedFd, RawFd}; // ❌ Requires #![feature(wasip2)]Solution:
- Created fork: https://github.com/avrabe/tempfile/tree/wasip2-rustix-fd-fix
- Removed WASI-specific fd trait implementations (they were just convenience delegates)
- Used std::fs instead of rustix for WASM targets to avoid API compatibility issues
Impact: Eliminated all unstable feature requirements from tempfile
2. tokio networking incompatibility
Problem: Registry features pulled in full tokio with networking features
reqwest→hyper→h2→tokio[full]- WASM only supports:
sync,macros,io-util,rt,time - Banned features:
net,fs,process,signal,rt-multi-thread
Solution: Made registry features optional for WASM builds
tokio = { workspace = true, optional = true }
registry = ["wac-resolver/registry", "dep:tokio", ...]Impact: Clean separation between local WAC functionality and registry networking
3. Runtime configuration
Problem: tokio's rt-multi-thread doesn't work on WASM (single-threaded environment)
Solution:
- Registry builds:
#[tokio::main(flavor = "current_thread")] - Non-registry builds:
futures::executor::block_on()for minimal async support
🚧 Remaining Challenges (for future work)
Full Registry Support on WASM
The tokio wasip2 patches (tokio-rs/tokio#6893) still require:
- Nightly Rust with
#![feature(wasip2)] - Corresponding mio patches (add
wasm32-wasip2support tokio-rs/mio#1836)
Status: Ecosystem patches exist but aren't merged/stable yet
🛠 Technical Approach Used
1. Dependency Analysis
cargo tree -i rustix --target wasm32-wasip2
cargo tree -i tokio --features registry2. Feature Engineering
- Made networking dependencies optional with feature flags
- Created WASM-compatible code paths
- Used conditional compilation extensively
3. Ecosystem Integration
- Patched dependencies with working forks
- Used development branches of tokio/mio with wasip2 support
- Created minimal, targeted fixes
📊 Build Configuration
Working WASM Build:
cargo build --target wasm32-wasip2 --no-default-features --features witRequired patches in Cargo.toml:
[patch.crates-io]
tokio = { git = "https://github.com/dicej/tokio", branch = "wasip2" }
mio = { git = "https://github.com/dicej/mio", branch = "wasip2" }
tempfile = { git = "https://github.com/avrabe/tempfile", branch = "wasip2-rustix-fd-fix" }🔧 Key Insights
- tempfile fd traits were not essential - removing them didn't break functionality
- WAC core doesn't need networking - registry is just for package downloads
- wasip2 ecosystem is close but not ready - patches exist but require nightly
- Feature flags are crucial - clean separation of concerns prevents dependency hell
🎉 What Works Now
- ✅ Component parsing and validation
- ✅ Component composition
- ✅ WIT interface processing
- ✅ Local file operations
- ✅ All core WAC functionality
⏭ Future Work
- Monitor tokio/mio PR progress for stable wasip2 networking
- Consider alternative HTTP clients for WASM (like web APIs)
- Submit tempfile fix upstream to help the ecosystem
- Optimize binary size (currently 110MB in debug mode)
🔗 Related Resources
This represents a significant step forward for WebAssembly component tooling accessibility and demonstrates that complex Rust applications can be successfully adapted for WASM targets with careful dependency management.