bytecodealliance
Node.js builtins
Tracking issue for supporting Node.js builtins (import fs from node:fs, ...), where each builtin can be individually turned on or off.
We should implement this layer in C++ (or Rust), and try to build optimized implementations.
I was wondering something you've almost certainly considered: Node.js compat is something I assume other WinterCG implementations would be interested in that too? Is there any work happening on a JS-based shim already? If not, could that potentially serve as a starting point?
A JS-based shim could well be a starting point, although in terms of that being a development blocker often a simple build step can also be used to build in Node.js compatibility just as well.
If someone wanted to work on an entirely inlined JS approach to builtins we could certainly accept those PRs as a start though.
There are JS-based shims, including browserify, yes. The biggest issue for us is that these often are built in a way that assumes that JS is faster to execute than it is in our environment. Because of that, I think it'd be unfortunate if we invested a large amount of energy into a JS based approach, instead of doing something native
I wanted to add async_hooks/AsyncContext as a interesting candidate. I was playing around getting Next.js routes to execute as components which worked well for simple API routes but as soon as it gets a bit more complex like the way cache invalidation is done, they leverage AsyncLocalStorage(ref https://nodejs.org/api/async_context.html#class-asynclocalstorage).
There's a TC39 AsyncContext proposal (https://github.com/tc39/proposal-async-context) in Stage 2. Cloudflare added async_hooks to workerd (https://blog.cloudflare.com/workers-node-js-asynclocalstorage/)
Something that's worth looking at here (thanks @calvinrp):
https://github.com/unjs/unenv
Would be nice to be able to opt-in (or opt-out) to node.js apis / globals being present in the env.
- Not sure what the binary size change looks like with more complete node.js apis but being able to opt-out of that extra size downstream (in componentizejs / jco commands) would be nice too (but secondary to the env changes).
Would also be great to opt-in (or opt-out) to the DOM / WinterTC apis / globals being present as well in the env.
