Support node-like module resolution in dev mode

[zhuhaow]

Add support for a node-like module resolution in workerd dev mode would make workerd play nicely with existing solutions.

Problem

Currently, when people use meta-frameworks such as qwik, remix, etc, they all expect to use the built-in dev server with all kinds of DX features. And most of these frameworks depend on Vite's dev server to provide most DX features.

However, Vite's dev server SSR support is not compatible with workerd (or any other edge runtimes that I'm aware of). Vite dev server expects the SSR will happen in node runtime so it loads the code "in-place" and does SSR in node runtime instead of the edge runtime. To make things faster, Vite will resolve and transform the requested modules on the fly as node imports them so things are always lazily processed. I created an issue here vitejs/vite#10770 proposing if it's possible to create a bundled script on request in the dev server.

On the other side, even if Vite does provide a bundled script, some frameworks, e.g., qwik, may still not work with workerd. This is due to in dev mode, qwik may load the component code with import. I created an issue here QwikDev/qwik#1984.

Root cause

All these incompatibilities happen because all these tools are designed without the edge runtime limitation in mind, so they do optimization by assuming everything will happen in node runtime with fs access and in the same process.

Solution

I'm wondering if it's possible on workerd side, that we can provide an interface for a special dev mode that is more compatible with node module resolution behavior, so we can hook workerd into existing tools and frameworks more easily. Because none of the issues above are trivial to fix, some parts of them even contradict the optimization they promise.

If, for example, in node we can programmatically have workerd load a script with a provided import/require, then all of these issues can be more easily fixed and we won't have to fix all existing and (probably most) new tools and frameworks by changing their design.

[kentonv]

I converted this into a discussion as it seems to be more of an idea than a specific actionable task.

For my part, I don't quite understand what you mean. How does supporting "node module resolution behavior" help with the problem of supporting these tools, exactly?

You imply that the use of import is inherently a problem. Why is that? workerd supports import.

[zhuhaow]

I reread my original issue and do find it quite confusing. I made a few mistakes and focused on the wrong problems actually.

Probably we don't need to change things from workerd side to support this.

In development, we want to get the result of change fast, so we try to lazily load/compile/translate code whenever possible. Today's meta frameworks (such as remix, next.js, solid start, Qwik City, Nuxt) use file system based routing. When a request comes in, it's quite straightforward to know which file is responsible to handle the request. So it makes sense to only process that file (and all modules that file imports).

All frameworks other than Next.js uses vite to do this. Vite will take the request, and let the developer provides a hook to provide the file to load to handle the request. Vite will recursively parse the file, find all imports (static or dynamic) from the AST, compile all imports, and update the import URL to the compiled output on disk. Then vite will load the module in place in the same node process and handle the request.

That means with the import support of workerd, we just need vite to support compiling the module without the assumption of node env and then we should be good to go.

A few questions:

1. Does workerd support dynamic imports? Vite doesn't support dynamic url (things like import("./user/" + username)) so it's okay if workerd doesn't support it. But what about static url?
2. We are supposed to use Miniflare in this case, right?
3. Is it ok to use Miniflare as a one shot request handler during development? Or would it be too slow?

[kentonv]

workerd does support dynamic imports, but only of files that are named in the config. That is, you can lazily parse a file by importing it dynamically. However, the file does have to exist at startup time. workerd won't see any changes made to the file after startup, unless you use --watch, in which case the whole process will restart on every change.

I think it'd be difficult to get workerd to dynamically load newly-generated code into the existing process. But, maybe if you import everything dynamically on-demand, then restarting the process won't be very expensive, since it won't actually reload any code until needed. Then you could use --watch mode and let Vite overwrite the code as needed?