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.