feat!: support file:// resolution

[hi-ogawa]

Description

Copying #18421 on top of main since its base branch #18361 is concerned with a different aspect of runner implementation.

The rational of supporting file:// is briefly mentioned here #18361 (comment). I think the current situation is:

• Node supports import "file://...
• Node and Vite supports import "/abs-path.js" on Unix, but for Windows, import "C:/abs-path.js" fails.
• For Vite, /@fs can be used to workaround.
• For Vite 6 module runner specifically (i.e. dev ssr), import "file://... works.
• User can use a plugin resolveId to resolve file://.

And the necessary decision is probably a one of

• keep it as is
• remove file:// support from Vite 6 module runner (this is partly done in PR 18361)
• support file:// for ssr dev/build (this PR)
• support file:// for both client and ssr dev/build

[hi-ogawa]

/ecosystem-ci run

[vite-ecosystem-ci]

📝 Ran ecosystem CI on 4e0b6fd: Open

suite	result	latest scheduled
astro	❌ failure	❌ failure
remix	❌ failure	❌ failure
sveltekit	❌ failure	❌ failure
vike	❌ failure	❌ failure
vite-environment-examples	✅ success	❌ 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

[sapphi-red]

I'm for supporting fileURLs in both client and SSR dev/build.

• Node and Vite supports import "/abs-path.js" on Unix, but for Windows, import "C:/abs-path.js" fails.

To clarify this part, I wrote down a support matrix.

type	example	Node	Deno	Bun	Vite
file URL	import "file://..."	✅	✅	✅	❌
absolute path (linux)	import "/home/foo.mjs"	✅	✅	✅	✅
absolute path (windows)	import "C:\\Users\\foo.mjs"	❌	❌	✅	✅
normalized absolute path (windows)	import "C:/Users/foo.mjs"	❌	❌	✅	✅
protocol relative URL (windows)	import "/C:/Users/foo.mjs"	✅	✅	❌	✅
drive relative file URL (windows)	import "/Users/foo.mjs"	✅	✅	✅	✅

[hi-ogawa]

Thanks for the summary! I didn't know the last two are possible on Windows. It looks like most of us agree with supporting this everywhere, so I'll go ahead removing ssr check and try adding tests for client dev/build.

[hi-ogawa]

/ecosystem-ci run

[vite-ecosystem-ci]

📝 Ran ecosystem CI on 582719f: Open

suite	result	latest scheduled
astro	❌ failure	❌ failure
nuxt	✅ success	❌ failure
redwoodjs	❌ failure	❌ failure
remix	❌ failure	❌ failure
sveltekit	❌ failure	❌ failure
vike	❌ failure	❌ failure
vite-plugin-svelte	❌ failure	❌ failure
vitest	❌ failure	❌ failure

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

[sapphi-red]

I removed ! from the PR title as I don't think this is a breaking change. But let me know if it's a breaking change.

[sapphi-red]

Thanks!

[hi-ogawa]

I removed ! from the PR title as I don't think this is a breaking change. But let me know if it's a breaking change.

Doesn't it have a similar effect as #17369 (comment)? Users will need enforce: true for user plugins to intercept file:// if they want to do something different from what this PR does for whatever reason.

[sapphi-red]

That's true. Yeah, let's add it back and add this PR to https://github.com/vitejs/vite/blob/main/docs/guide/migration.md#advanced.