fix(runner): replace runner path normalization with fetchModule resolve

[hi-ogawa]

Description

• closes virtual file system is broken in v6 #18223

Not so confident that this is a proper fix nor the issue needs fix, but I'm thinking about what would require to support #18223 and hopefully it helps deciding the fate of the issue (bug or wontfix).

One thing I noticed that it looks possible to dedupe/normalize /abs-path-to/src/etc -> /src/etc on server side (fetchModule) and module identity is still kept intact on runner side since they are keyed by resolved id. For FetchModuleResult.cache detection, I replaced getModuleByUrl with ensureEntryFromUrl and I'm wondering what's the downside of this.

todo

• decide on file:// support
  • it doesn't work on build (nor v5 ssr dev, nor client dev/build), so for now, I think it's better to remove dev only file:// support. It's still possible to use custom plugin resolveId to resolve file:// and I added tests for this usage.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[hi-ogawa]

normalizeAbsoluteUrl also noramlizes file:///... to support this test case, but I'm not sure if we needs to keep this if we go with externalizing file:// entirely #17369. Also v5's ssrLoadModule('file://') doesn't seem to work either.

vite/packages/vite/src/node/ssr/runtime/__tests__/server-runtime.spec.ts

Lines 17 to 20 in 5e8e7ec

	// loads the same module if id is a file url
	const fileUrl = new _URL('./fixtures/simple.js', import.meta.url)
	const mod2 = await runner.import(fileUrl.toString())
	expect(mod).toBe(mod2)

[hi-ogawa]

/ecosystem-ci run

[vite-ecosystem-ci]

📝 Ran ecosystem CI on f001b7d: Open

suite	result	latest scheduled
astro	❌ failure	❌ failure
remix	❌ failure	❌ failure
sveltekit	❌ failure	❌ failure
unocss	❌ failure	❌ failure
vike	❌ failure	❌ failure
vitest	❌ failure	❌ failure

✅ analogjs, histoire, ladle, laravel, marko, nuxt, previewjs, quasar, qwik, rakkas, redwoodjs, storybook, vite-environment-examples, vite-plugin-pwa, vite-plugin-react, vite-plugin-react-swc, vite-plugin-svelte, vite-plugin-vue, vite-setup-catalogue, vitepress, vuepress

[hi-ogawa]

/ecosystem-ci run

[vite-ecosystem-ci]

📝 Ran ecosystem CI on b1236bf: Open

suite	result	latest scheduled
astro	❌ failure	❌ failure
remix	❌ failure	❌ failure
sveltekit	❌ failure	❌ failure
vike	❌ failure	❌ failure
vite-environment-examples	❌ failure	❌ failure
vite-plugin-svelte	❌ failure	❌ failure
vitest	❌ failure	❌ failure

✅ analogjs, histoire, ladle, laravel, marko, nuxt, previewjs, quasar, qwik, rakkas, redwoodjs, storybook, unocss, vite-plugin-pwa, vite-plugin-react, vite-plugin-react-swc, vite-plugin-vue, vite-setup-catalogue, vitepress, vuepress

[sheremet-va]

• it doesn't work on build (nor v5 ssr dev, nor client dev/build), so for now, I think it's better to remove dev only file:// support. It's still possible to use custom plugin resolveId to resolve file:// and I added tests for this usage.

file:// works in production though. It's a valid (and the only) way to pass down the full path on Windows, for example. It also works in vite-node:

runner.executeId('file:///C:/Users/name/dev/index.js')

This is a valid Node.js code:

await import('file:///C:/Users/name/dev/index.js')

[hi-ogawa]

I agree that file:// should be supported in some way, but I'm worrying about the inconsistency in current state. Putting aside client case, I think we want this to work consistently for ssr dev/build at least. Let me think about how to move custom file url resolve to core.