Repository navigation
Request: mark WASI as stable #46254
Description
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
WASIconstructor, 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.
Activity
GeoffreyBooth commentedon Jan 18, 2023
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 commentedon Jan 18, 2023
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 commentedon Jan 18, 2023
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 commentedon Jan 18, 2023
I'm +1 for marking it stable. I'm also ok in unflagging it and keep it experimental with or without a warning.
GeoffreyBooth commentedon Jan 18, 2023
Okay, so some proposed next steps:
I think that’s it?
mhdawson commentedon Jan 20, 2023
+1 from me on that as well
phated commentedon Jan 29, 2023
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 commentedon Jan 31, 2023
@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?
wasi: add support for version when creating WASI
mhdawson commentedon Feb 1, 2023
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 commentedon Feb 1, 2023
@mhdawson sorry to be an inconvenience, but I'll be traveling next week. Could we aim for the week after?
mhdawson commentedon Feb 1, 2023
@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.
ospencer commentedon Feb 1, 2023
All set; thanks for organizing @mhdawson!
17 remaining items
mhdawson commentedon Mar 28, 2023
PR to remove need for command line flag - #47286. WASI is still documented as experimental.
JamieMagee commentedon Apr 16, 2023
It looks like the linked PR was merged, and I can't see
--experimental-wasi-unstable-preview1in recent nightlies. Can this issue be closed?tniessen commentedon Apr 16, 2023
No, WASI remains experimental until the API is finalized.
github-actions commentedon Oct 14, 2023
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
cjihrig commentedon Nov 2, 2023
It's worth noting that Deno has deprecated their WASI implementation "due to low usage and minimal feedback from the community."
d3lm commentedon Nov 10, 2023
We added WASI support to WebContainers (same code as Node.js) now and it's really essential for running native code and already powers our experimental Python support. Wanted to add an extra data point. I think WASI is going to get some traction as it stablized and it hits 1.0. WASI is already used quite a bunch on the Edge, e.g. Cloudflare has announced WASI support for Cloudflare Workers so I'd personally not like to see WASI being deprecated for Node.js.
cjihrig commentedon Nov 10, 2023
I'm not sure what you mean by "same code as Node.js" but you could implement WASI as a compiled addon or try something like jco.
There is a pretty big difference between what WASI was in snapshot 1 and its direction now, and I don't believe it makes sense to have it in core anymore (I'm not sure of any JS runtime working on anything beyond snapshot 1). We also have the problem of maintaining WASI in core. There is such little interest in maintaining it that the project recently marked its WASI implementation as insecure rather than fix a small to medium sized bug.
guybedford commentedon Nov 14, 2023
To try to fill in some of the blanks here on stability:
new WASI({ version: 'preview1' })can laregely be considered stable at this point in Node.js.I'm actively working on the preview2 support in userland via the jco project for Node.js currently, and hope to use this implementation experience to feed back some suggestions for preview2 support in core. Having support in core will allow optimization opportunities not otherwise possible in userland, so I think that would be very worthwhile and I'm actively interested in working on these directions myself.
If anyone else is interested in working on WASI from the security properties to preview2 support designs, the @nodejs/wasi team is active and has meetings every two weeks, with the next on 22 November. Agendas for the meetings are posted in https://github.com/nodejs/uvwasi/issues a few days before.
d3lm commentedon Nov 15, 2023
@guybedford I would be interested in working on WASI because we have interest in this at StackBlitz and I think it'd be really nice if we could keep WASI in the core of Node.js. It just allows for a handful of optimizations, as Guy pointed out, that wouldn't be possible otherwise. Furthermore, I see it as another battery included in Node.js and from a DX perspective it's much nicer if you didn't have to rely on a separate project.
cjihrig commentedon Nov 15, 2023
I'm genuinely curious what the optimizations are.
Technically, no changes to libuv are required. The
openat()functionality could be added to Node.js or uvwasi. I'm assuming uvwasi is not an option with jco though.I also have a few questions:
guybedford commentedon Nov 16, 2023
Certainly
wasi-clialong with its associated worlds. Supportingwasi-httpwould be great to see as well.There's high-level and low-level bindgen, and we are doing high-level bindgen currently in the name of correctness and because it should always be supported to directly call to WASI from JS (since that is what high-level bindgen is). Anything upstreamed into Node.js would be based on performance-optimized low-level bindgen that uses the direct core component model ABIs. We might need something like a
WASI.instantiateto properly encapsulate this process, although Node.js should also support the high-level bindings too, so that it may be possible without and just having a property on the high-level function pointing to the low-level implementation.That would then be somewhat analogous to WebAssembly function imports, where the JS function wrapper is a high-level JS function that is passed from JS into Wasm instantiation, but when passing that import to a Wasm core module, it instead reads out and attaches to the direct low-level function not the high-level JS function wrapper.