PR #91 introduced Wasm host tools using WASIp1 command modules (one --tool NAME=WASM flag per tool, JSON on stdin/stdout). WASIp1 was the right starting point for simplicity and broad toolchain support, but component-model (WASIp2/p3) reactor-style modules would unlock:
- Multi-tool modules — a single
.wasm component could export multiple tools, enabling --tools component.wasm instead of one flag per tool
- Auto-registration from the export list — no manual name mapping needed
- Access to the latest Wasm tooling — componentize-py, jco, wasm-tools, and the broader component ecosystem
- Composability — combine tool components without recompilation
This would require a separate registration and lifecycle model (reactors are long-lived, not fresh-instance-per-call like the current command ABI).
The wasmtime component-model runtime is already substantially in the dependency tree (the current implementation imports from wasmtime_wasi::p2::pipe), so the incremental cost may be smaller than it appears.
PR #91 introduced Wasm host tools using WASIp1 command modules (one
--tool NAME=WASMflag per tool, JSON on stdin/stdout). WASIp1 was the right starting point for simplicity and broad toolchain support, but component-model (WASIp2/p3) reactor-style modules would unlock:.wasmcomponent could export multiple tools, enabling--tools component.wasminstead of one flag per toolThis would require a separate registration and lifecycle model (reactors are long-lived, not fresh-instance-per-call like the current command ABI).
The wasmtime component-model runtime is already substantially in the dependency tree (the current implementation imports from
wasmtime_wasi::p2::pipe), so the incremental cost may be smaller than it appears.