Consider providing a v8/worker-based development runtime

[jplhomer]

Right now, Hydrogen uses Vite which uses Node.js as the runtime.

It uses Node.js for a lot of reasons, but primarily:

• You can require/import other modules at runtime without bundling
• It can be run anywhere that has Node installed

However, with Oxygen being the primary target for Hydrogen deployments, and Oxygen being a worker/v8 runtime, we're asking developers to use a runtime they most likely won't be deploying to.

This could mean the developer introduces a dependency that isn't compatible with v8 isolates, or perhaps a node built-in that doesn't exist.

If we implement a way to use oxygen-run or miniflare as the primary development server, it would solve this inconsistency. Cloudflare has cloudflare dev which proxies to the edge to accomplish this same behavior, but it requires a bundle to be built each time (so it's slower).

I think this would also be tricky to do considering Vite is written in Node.js. But I think others in the Vite community would find value here, and maybe it's something we can contribute upstream (like a bring-your-own-development-runtime plugin).

Pinging @frandiox for their thoughts! cc @genevieve who is leading the Oxygen runtime team and contributing to oxygen-run.

[frandiox]

In another project I have similar to Hydrogen, the biggest source of problems for the users is basically differences in Node vs CFW runtime. Therefore, I agree having this runtime available locally (or somewhere fast enough) is a must for us at some point.

The way I implemented this some time ago for that other project was basically with a build-watch in Vite and serving it from Miniflare. Even though it's not ideal, it is not so slow because Vite watches and rebuilds only things that change, and Miniflare can detect this and reload the server automatically.

We could research how to plug Vite to Miniflare/OxygenRun more seamlessly, or build a new development server that replaces Vite. However, my gut tells me any of this would require a huge effort 😓

On the other hand, we could polyfill our current Vite/Node development environment with all the Web Standards and Worker/Oxygen APIs (atoa, btoa, caches, WebSocketPair`, etc). This still doesn't add the constraints (i.e. restrict Node-only APIs) of a CFW/Oxygen but enables the developer to use all the features in development. In addition to this, we could provide the approach mentioned above (build watch + serve in Oxygen runtime) as a "preview" mode that can be checked from time to time to make sure the app keeps working in CFW/Oxygen.

Thoughts? 🤔

---

About the polyfills, if oxygen-run is built in JavaScript (like Miniflare), we could just reuse the same logic if it exports its internals. Example of this using Miniflare here.
If it's written in other language I guess we would need some extra effort for this.

[genevieve]

Hey Fran.

oxygen-run is written in Go.

Part of the APIs that oxygen-run/oxygen-sws (the actual prod server) are written in Go (such as fetch, cache, console), and the rest are written in JS.

Two relevant folks for this conversation:

• @maxshirshin who is championing the improvement and development of Oxygen's runtime APIs
• @mklocke-shopify who is championing the developer experience with oxygen-run

[mklocke-shopify]

Just to followup on this in terms of what we've been working on. As Gen mentioned the actual oxygen-run is written in Go and the server is launched with a binary. There is ongoing work to integrate this into the hydrogen e2e process (see here if you're interested) - the idea here is to allow us to run some e2e tests against hydrogen running with oxygen-run.

It would be awesome if we could abstract oxygen-run in some way that allows us to integrate it nicer into a JS/TS environment (with like an NPM package or something) so that developers can pull that really easily into any testing they want to do. Really something more similar to Miniflare and Wrangler to make it a nice developer experience.

I just am not sure how we would even go about doing that, if we could do We could research how to plug Vite to Miniflare/OxygenRun more seamlessly something like that as you mention but no idea how to finish wire this up with a binary that we create. Somehow wrap our Go server in Vite or Node? Just totally thinking out loud here.

Would definitely be down to chat more about this! Its something that @jplhomer and I have chatted briefly about as well but only at a very high level.

[frandiox]

I just am not sure how we would even go about doing that, if we could do We could research how to plug Vite to Miniflare/OxygenRun more seamlessly something like that as you mention but no idea how to finish wire this up with a binary that we create. Somehow wrap our Go server in Vite or Node? Just totally thinking out loud here.

To be honest I'm not even sure if it's possible to connect Vite to the binary while running both at the same time 🤔 (without a previous Vite build => binary). There are so many things I ignore here, but just to do some brainstorming...
If we import the binary somehow in the Vite server and let it handle the request, the binary should either:

1. Import the app code from the filesystem. However, this means Vite wouldn't be able to apply its magic (code transformations). Unless we somehow also import the Vite transformer logic in the binary as well 🤯
2. Let Vite import the app code and... pass a function/callback to the binary? Is this possible somehow? Perhaps with WASM?