fix(server): ensure consistency for url to file mapping in importAnalysis and static middleware

[dominikg]

Description

fixes #6516

includes slight update to fsPathFromId to avoid stripping FS_PREFIX if it isn't set

Additional context

there may be more at play here and deeper analysis/ more testing of the code in static middleware is warranted.
The way url, id and file system path are handled currently isn't transparent with hardcoded special treatment even outside of utils.

Maybe switching path to pathe could be an option to avoid some of the inconsistencies?

cc @antfu @patak-dev

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[patak-dev]

Looks like a good refactoring, but the windows fails look legit. So something is missing.
+1 to start using pathe, it seems to be working very well for Vitest

[bluwy]

Didn't notice the failing windows test after the approval 😅 but yeah that should be taken of too

[dominikg]

I managed to get my windows vm broken and won't restore it before getting a new workstation set up (finally more ram).

If someone wants to debug this in the meantime, go ahead. Otherwise it'll be a few days before i can

[dominikg]

debug output of pnpm dev in packages/playground/css

  vite:resolve 0.76ms /linked.css?direct -> c:/Users/IEUser/dev/vite/packages/playground/css/linked.css?direct +0ms
The request url "c:\Users\IEUser\dev\vite\packages\playground\css\linked.css" is outside of Vite serving allow list.

- /c:/Users/IEUser/dev/vite
- /C:/Users/IEUser/dev/vite/packages/vite/dist/client

Refer to docs https://vitejs.dev/config/#server-fs-allow for configurations and more details.

  vite:time 8.80ms /linked.css +0ms

[dominikg]

note the extra leading slash in front of the logged allowed directories. this is added here:

vite/packages/vite/src/node/server/index.ts

Line 696 in a012644

return ensureLeadingSlash(normalizePath(path.resolve(root, dir)))

i'm not entirely sure why because path.resolve should always return an absolute path.

another oddity i noticed is that the drive letter c is lowercase in the first but uppercase in the second entry. Is windows fs still case insensitive and do we have to make an insensitive comparison in that case?

I'm this close to not ever going to touch anything windows again ><

[dominikg]

@bluwy notified me that normalizePath is public api so this would be a breaking change. i'll try to refactor it, gotta come up with a better idea first tho

[patak-dev]

I think we shouldn't do the normalization to lowercase in this PR. We had a few requests to do so before but decided that it was better to ask the user to properly name paths. Something may work in windows but fail in linux if we had this in. Touching normalizePath is also quite a big change. Let's check the rest of the issues without it

[patak-dev]

Could you send these two timeouts in a separate PR @dominikg?

[dominikg]

done #6843

[patak-dev]

To play safe here, let's merge this one in the 2.9 beta (that given the number of PRs we already queued we should start soon anyways)