Stream: wasi

Topic: Stabilizing wasi/cli exit-with-code

SingleAccretion (Aug 14 2025 at 20:41):

A while ago we added cli exit-with-code to the wasi-cli world, but it is still listed as "unstable" in https://github.com/WebAssembly/wasi-cli/blob/07e4b66066ee7c183b10e8ee696e5aa571e9fbef/wit/exit.wit#L15 so (I presume) we can't really use in e. g. wasi-libc yet. I am wondering what would the process be where the end result is it being usable from libc.

Alex Crichton (Aug 14 2025 at 20:47):

I think the steps would look more-or-less like:

• Formally propose in the WASI SG that this should become a stable API (I'm a bit hazy on this but if you make a presentation with your case I suspect that's more-or-less sufficient)
• Update the WITs
• Wait for a WASI release (once every 2 months)
• Update Wasmtime with the new WITs plus removal of the feature (e.g. it's always on-by-default now)

The next big question is when to update wasi-libc. Unfortunately there's not a great answer there just yet. There's no preexisting policy about which version of the WITs are used to generate bindings in wasi-libc (it's only just now recently getting support for wasip2 natively). Additionally with Wasmtime's p1-to-p2 adapter there's no formal policy yet about what versions of WASI to support.

Basically it's required to get this to a stable API to use, but after that it's not 100% clear when default tooling can use this. If you're interested in pushing this forward I'd recommend starting with a presentation to the WASI SG and then getting it out in Wasmtime, and then after that we can see where we're at and what, if any, policies we need

SingleAccretion (Aug 14 2025 at 20:58):

Oh, thank you for such a quick and comprehensive reply :). I'll start working though the steps...

Joel Dice (Aug 14 2025 at 21:05):

Regarding which WITs to use for wasi-libc: this is yet another example of where optional imports would be super useful. wasi-libc could optionally import exit-with-code and fall back to the old exit if needed.

Alex Crichton (Aug 14 2025 at 21:28):

agreed yeah, although the irony with optional imports is that they're mostly only useful if they were implemented a long time ago, if we were to implement optional imports today it'd still take a long time to percolate to all the runtimes and be usable for wasi-libc (same usability issues as using a newer WASI API on first-time-use)

Joel Dice (Aug 14 2025 at 21:41):

All the more reason to do it ASAP.

Alex Crichton (Aug 14 2025 at 21:51):

easier said than done :)

Alex Crichton (Aug 19 2025 at 18:05):

On a semi-related note, inspired by this, we had some discussion today about this and I wrote down a plan: #wasm > Optional imports in the component model @ 💬

Last updated: Dec 06 2025 at 06:05 UTC