Request: mark WASI as stable

[cjihrig]

What is the problem this feature will solve?

WASI support has been in Node for a few years now, but still requires a CLI flag to use. Node's WASM/WASI story appears to be pretty competitive, but people call out the fact that it requires a flag to use (https://00f.net/2023/01/04/webassembly-benchmark-2023/). From what I understand, some other projects such as Kotlin are currently using Node's WASI implementation, and Grain is planning to as well.

What is the feature you are proposing to solve the problem?

A few people (@mcollina, @guybedford) have suggested that we should unflag it at this point. I support this, but there are a few things that we would need to address:

• We need a way to support multiple versions of WASI. snapshot1 is what we currently support, but work is underway to release snapshot2. This would require changes in Node's API, as well as the underlying WASI implementation (currently in uvwasi). On the Node side, I would recommend passing the WASI version to the WASI constructor, instead of specifying it from the command line (new WASI({ version: 'preview1' })). The uvwasi changes would be more in depth, which brings me to the next point.
• No one is actively working on uvwasi anymore. When I originally wrote uvwasi, I was able to spend essentially as much time as I needed during working hours. That is no longer the case, and hasn't been in years now. I transferred the project into the nodejs GitHub org, hoping that other people would pick up maintenance, but that hasn't happened outside of some contributions from people from other projects. We should not stabilize WASI in Node if no one will spend any time working on it. In addition to adding support for the upcoming snapshot2, there is a new API that was (very surprisingly) added to the existing snapshot1 that would allow servers written in WASM to be supported.

What alternatives have you considered?

Leaving things as they are.

[GeoffreyBooth]

For me the question is, what potential breaking changes might we want to make to this API after making it stable? Only the support of the next WASI version? So if we make the desired WASI version a required part of the constructor, would that cover us?

As for the maintenance aspect, that’s a general question we should probably address separately: is it better to have an API in core that’s essentially unmaintained, versus not having it there at all. I don’t know, but I don’t think it’s specific to this. We have plenty of unmaintained APIs in core already, both experimental and stable.

[cjihrig]

For me the question is, what potential breaking changes might we want to make to this API after making it stable? Only the support of the next WASI version? So if we make the desired WASI version a required part of the constructor, would that cover us?

I don't think we've shipped any breaking changes thus far - everything has been semver minor or bug fixes IIRC. I think the biggest unknown there is how WASI itself evolves. For example, they recently added a new API to an existing snapshot version without any type of version change. They could theoretically remove an API too.

[GeoffreyBooth]

I think the biggest unknown there is how WASI itself evolves.

I have the same issue with JSON modules / import assertions. We unflagged that feature a long time ago (years?) and I want to mark it stable, but the TC39 proposal is sitting at Stage 3. Since the proposal/syntax itself could theoretically still change, I feel like I can’t mark our implementation of it as stable until then.

On the other hand, it’s not that once something becomes stable it can never get breaking changes; they just have to come as part of a semver-major, which happens annually. So maybe we shouldn’t be scared off by perpetually experimental specs and just go ahead and mark our features as stable, and if the spec changes then we’ll ship those changes in the next major.

In the WASI case if the constructor can be used as a way to essentially request a particular spec version, that sounds like a great solution that I wish I had for import assertions, and WASI going stable seems especially low risk.

[mcollina]

I'm +1 for marking it stable. I'm also ok in unflagging it and keep it experimental with or without a warning.

[GeoffreyBooth]

Okay, so some proposed next steps:

• A PR to add the version option to the constructor, and probably make it required. Land this and then let some time go by for folks to try it out and report issues.
• A PR to make WASI stable and drop the flag/warning. This PR should also update the docs to include some text that the WASI spec is itself in flux, and that changes to the spec that would result in breaking changes to Node will arrive in semver-major updates in Node. Hopefully the new constructor will allow most spec changes to land without them needing to be breaking.

I think that’s it?

[mhdawson]

I'm +1 for marking it stable. I'm also ok in unflagging it and keep it experimental with or without a warning.

+1 from me on that as well

[phated]

Having uvwasi be actively maintained is something @ospencer and I are really interested in, both for nodejs and WAMR support (they currently have it marked as experimental too). Please let us know how we can help.

[mhdawson]

@ospencer, @phated if you two have time to contribute I can set up a meeting with myself and @cjihrig to discuss how to get started and some specific work to get started on. Does that make sense?

[mhdawson]

Link for doodle to discuss contributing to uvwasi - https://doodle.com/meeting/participate/id/e36JQMOd
@ospencer, @phated, @cjihrig could you fill in your availability?

If there are others interested in contributing to uvwasi as well please feel to join as well.

[cjihrig]

@mhdawson sorry to be an inconvenience, but I'll be traveling next week. Could we aim for the week after?

[mhdawson]

@cjihrig ack doodle updated to be for times the week after - https://doodle.com/meeting/participate/id/e36JQMOd

@ospencer, @phated if you already voted please look and vote again.