vite:resolve plugin incorrectly resolves knownJsSrcRE files from root

[GrygrFlzr]

Describe the bug

vite/packages/vite/src/node/utils.ts

Line 109 in 98d95e3

const knownJsSrcRE = /\.((j|t)sx?|mjs|vue|marko|svelte)($|\?)/

When attempting to access any files with an extension that matches the knownJsSrcRE regex, the vite:resolve plugin attempts to load them from the root of the filesystem. The following code in the plugin is the branch taken by such files.

vite/packages/vite/src/node/plugins/resolve.ts

Lines 120 to 128 in 98d95e3

	// URL
	// /foo -> /fs-root/foo
	if (asSrc && id.startsWith('/')) {
	const fsPath = path.resolve(root, id.slice(1))
	if ((res = tryFsResolve(fsPath, options))) {
	isDebug && debug(`[url] ${chalk.cyan(id)} -> ${chalk.dim(res)}`)
	return res
	}
	}

If the file exists at root and does not exist in the static assets directory, the plugin will resolve to the root file.

Reproduction

Add a test.svelte file at the root. Then, initialize a vanilla Vite template and run Vite in debug mode.

npm init @vitejs/app resolve-bug
# choose vanilla
cd resolve-bug
npm i
npm run dev -- --debug

Visit http://localhost:3000/test.svelte

  vite v2.4.1 dev server running at:

  > Local: http://localhost:3000/
  > Network: use `--host` to expose

  ready in 204ms.

  vite:resolve 2ms   /test.svelte -> D:/test.svelte +0ms
  vite:spa-fallback Not rewriting GET /test.svelte because the path includes a dot (.) character. +0ms
  vite:time 8ms   /test.svelte +0ms

The file is not loaded in an environment with no plugins, but combined with plugins such as vite-plugin-svelte it actually loads the file from root and resolves it if server.fs.strict is disabled, taking priority over source code (though lower priority than the static asset public directory).

System Info

System:
    OS: Windows 10 10.0.22000
    CPU: (16) x64 AMD Ryzen 7 3700X 8-Core Processor
    Memory: 10.89 GB / 31.93 GB
  Binaries:
    Node: 14.16.0 - C:\program files\nodejs\node.EXE
    Yarn: 1.22.10 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 6.14.13 - C:\program files\nodejs\npm.CMD
  Browsers:
    Chrome: 91.0.4472.124
    Edge: Spartan (44.22000.1.0), Chromium (91.0.864.59)
    Internet Explorer: 11.0.22000.1
  npmPackages:
    vite: ^2.4.1 => 2.4.1

Used Package Manager

pnpm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

[bluwy]

I tested this on macos on both Vite 2.4.1 and 2.8.6, and it seems to be working for me:

  vite v2.4.1 dev server running at:

  > Local: http://localhost:3000/
  > Network: use `--host` to expose

  ready in 131ms.

  vite:resolve 1ms   /test.svelte -> /Users/bjorn/Work/repros/vite-root-test/test.svelte +0ms
  vite:time 14ms  /test.svelte +0ms

So it seems like a Windows only issue

[sapphi-red]

I tested this on windows on Vite 2.4.1 and 2.9.5 and I was not able to reproduce it.
It was resolved in the following order on both versions.

• C:\path\to\workspace\public\test.svelte
• C:\path\to\workspace\test.svelte
• C:\test.svelte

[sapphi-red]

Or does it mean /test.svelte should not be resolved to C:\test.svelte?
Which the code is here.

vite/packages/vite/src/node/plugins/resolve.ts

Lines 237 to 241 in 434bb5c

	// absolute fs paths
	if (path.isAbsolute(id) && (res = tryFsResolve(id, options))) {
	isDebug && debug(`[fs] ${colors.cyan(id)} -> ${colors.dim(res)}`)
	return res
	}