Idea: what would it take to run wrangler in a non-Node environment?

[GregBrimble]

With the recent WfP GA announcement, what would it take to be able to offer a decent Workers development experience for people who want to build the platform entirely on Workers?

Right now, if platforms want their users to be able to author the Workers in a fully-fledged environment with multiple files and TypeScript and all the features that wrangler handles in the bundling process, they'd need to run wrangler (or their own tool) in a proper Node environment. This is pretty painful if everything else can be done in the Cloudflare Developer Platform.

So, a wishlist:

• Remove all Node APIs from the core of wrangler and move them into exclusively bin/wrangler.js
• Option to use esbuild-wasm
• We're already using the platform-agnostic Fetch API (powered by undici's polyfill). Use instead globalThis.fetch if present.
• Similarly, either abstract out fs usage and accept an fs-compatible API, or refactor to use something else more platform-agnostic (FileSystem API?)
• wrangler publish --dry-run producing an output that we can give to the Workers for Platforms API
• unstable_dev working in a browser and document an example of how to use it to power an iframe

Pages is doing something somewhat related to the penultimate point about a portable Workers format right now internally anyway. Would be good to see if there's interest in making that a public thing too. Regardless of WfP, there's probably a valid use-case where you want to wrangler publish --dry-run and then later wrangler publish <artifact>.

And finally, Pages also has a use-case today for wrangler pages functions build working in the browser. This needs the esbuild-wasm and fs pieces.