fix: prevent null pathname error

[sapphi-red]

Description

This PR fixes the issue described at #9036.

The issue happens when

• the resolved id starts with \0virtual:
• the resolved id ends with an extension

close #9036

Additional context

---

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.

[sapphi-red]

resolveUrl is called with both rollup-space URL and browser-space URL.
Is this function intended to be called with both? Does this need to be resolved to a same url? (currently it doesn't)

You can check this by adding this line here and running playground/resolve.

if (url.includes('@virtual-file')) console.trace(url, resolved?.id, resolved?.id.replace('\0', '!0!'))

[patak-dev]

I think it isn't clear, it is a similar context to ssrLoadModule as explained in #9124 (comment). In Vite 4 we could review if we should for resolveUrl to always be in a given space, but since ssrLoadModule already accepts both, maybe we should also unwrap the id and replace to \0 as a guard at the start of it? If not we should review where is it being called with a URL out in browser space and pre-unwrap it.
Looks like this ensure has receiving browser-space URLs since before the release of Vite 2. See 8d8e2cc#diff-f2f744fef86a2c562dd5142240912f7a2d28404fac536740a2424daf628aa609R208

I don't know what is the best here during v3. The module graph is user-facing, so if we start accepting both then it may be hard to properly decode/encode.

Maybe we could still try to keep this function as is, and pre-unwrap in the places we are missing? We could already create the toRollupURL helper and use it for these places?

For reference, in the module graph we have:

• urlToModuleMap that maps a Rollup-space URL to a Module
• idToModuleMap that maps a resolved id to a Module

Since we are calling resolveUrl with both internally, we could review if what we really want in the graph is Browser-space URL or Rollup-space URLs, but since in both transformRequest and in ssrLoadModule we are using Rollup-space URLs when calling it I think it the above is fine and we should expect to see \0 and unwrapped ids (no /@fs/, etc) when exploring the module graph by URL. cc @antfu, just in case you have seen this in your plugins.

[sapphi-red]

Umm, it seems it requires much more work. I feel I need to read though all the code if I'm going to tackle this.
I'll leave this one as-is in this PR.

[patak-dev]

Yes, and maybe it is better, as it is unrelated to the fix this PR is targeting.
We can continue to work on this on future smaller PRs, and do a full review for 3.1.
Thanks a lot @sapphi-red!