Investigate the `fetchModule`'s `cloudflare:` catch

[dario-piotrowicz]

In fetchModule, if there is an error we have this catch logic:

vite-plugin-cloudflare/packages/vite-plugin-cloudflare/src/miniflare-options.ts

Lines 230 to 237 in 7adf439

	if (moduleId.startsWith('cloudflare:')) {
	const result = {
	externalize: moduleId,
	type: 'module',
	} satisfies vite.FetchResult;
	return new MiniflareResponse(JSON.stringify(result));
	}

that externalizes cloudflare:* modules

Is this really correct?

Shouldn't cloudflare:* modules be externalized already?

vite-plugin-cloudflare/packages/vite-plugin-cloudflare/src/cloudflare-environment.ts

Lines 171 to 175 in 7adf439

	external: [
	'cloudflare:email',
	'cloudflare:sockets',
	'cloudflare:workers',
	],

(this probably only applies to build 🤔)

I feel like we might be missing some config here, and we probably should not get cloudflare:* in the fetchModule 🤔
(or if this is ok it should be clear as to why we do need this ad-hoc module handling)

[navaru]

From my understanding, __VITE_FETCH_MODULE__ is a service binding called within miniflare, by a module runner to fetch modules using vite's dev environment.

Simplified:

1. miniflare: moduleRunner.import(moduleId)
2. miniflare: await env.__VITE_FETCH_MODULE__.fetch(moduleId, imported, options)
3. vite: viteDevServer.environments[name].fetchModule(moduleId, imported, options)

Importing a file worker.ts which imports "cloudflare:email" will throw an error and will be caught by the above and marked as external, only available in miniflare.

[dario-piotrowicz]

I think it all boils down to this ( source ):

// builtins should always be externalized
if (url.startsWith('data:') || isBuiltin(url)) {
  return { externalize: url, type: 'builtin' }
}

when you import directly from userland code this dev environment fetchModule is used, but since isBuiltin is hardcoded we have no way to tell the dev environment that the module is a built in one, unless, as we currently do, we specifically return an externalized module in our fetchModule implementation 😕

I think this might be expected then... 😕

[dario-piotrowicz]

This might be addressed by vitejs/vite#18584