fix(rsc): fix loadModuleDevProxy with @cloudflare/vite-plugin

[jamesopstad]

Description

Fixes cloudflare/workers-sdk#11359.

These changes defer accessing the dev server URL until it is used. This ensures compatibility with recent versions of @cloudflare/vite-plugin. Previously, the assumption was made that the server is started before the entry module is transformed but this no longer holds true.

[hi-ogawa]

I'm happy to have a fix like this here, but I'm wondering if @cloudflare/vite-plugin's behavior is now breaking conventions of plugin hook lifecycle. Doesn't it currently run resolveId/transform before buildStart? Or is it just for configureServer?

[jamesopstad]

I'm happy to have a fix like this here, but I'm wondering if @cloudflare/vite-plugin's behavior is now breaking conventions of plugin hook lifecycle. Doesn't it currently run resolveId/transform before buildStart? Or is it just for configureServer?

It doesn't run resolveId before buildStart. This isn't possible, as far as I know, because buildStart is called inside resolveId (https://github.com/vitejs/vite/blob/df5a30d2690a2ebc4824a79becdcef30538dc602/packages/vite/src/node/server/pluginContainer.ts#L368-L371).

What it does do now is make a request inside the configureServer hook that evaluates the user's entry module. I agree this is a little unconventional but we need to get the runtime types of the exports in the user's entry module during server initialisation and I can't think of another way to do that. I would be interested to know if you have concerns about this approach though and if it risks other breakages.

In this particular case @vitejs/plugin-rsc was assuming that the server is ready before transform is called and I don't think that's a safe assumption to make. transformRequest or warmupRequest could also be called before this, for example.

[hi-ogawa]

What it does do now is make a request inside the configureServer hook that evaluates the user's entry module. I agree this is a little unconventional but we need to get the runtime types of the exports in the user's entry module during server initialisation and I can't think of another way to do that. I would be interested to know if you have concerns about this approach though and if it risks other breakages.

I think it's mostly safe, but in the past, I remember there was an issue related to doing transform (e.g. ssrLoadModule) before or during configureServer. Vitest had a pattern like that and broke some plugins, then we just made configureServer as post hook and avoided the issue. vitest-dev/vitest#6584 Not sure if this is relevant now though.

That said, I also agree there's some oddity with what loadModuleDevProxy is trying to achieve, so if we can make it more robust, that's great. I'll merge this and will release a patch later. Thanks for the fix 🙏