Vite: Don't rebase urls that appear to be aliases

[philipp-spiess]

Closes #16039

This PR changes our URL rebasing logic used with Vite so that it does not rebase URLs that look like common alias paths (e.g. urls starting in ~, @ or #, etc.). Unfortunately this is only an approximation and you can configure an alias for a path that starts with a regular alphabetical character (e.g. foo => ./my/foo) so this isn't a perfect fix, however in practice most aliases will be prefixed with a symbol to make it clear that it's an alias anyways.

One alternative we have considered is to only rebase URLs that we know are relative (so they need to start with a .). This, however, will break common CSS use cases where urls are loaded like this:

background: image-set(
  url('image1.jpg') 1x,
  url('image2.jpg') 2x
);

So making this change felt like we only trade one GitHub issue for another one.

In a more ideal scenario we try to resolve the URL with the Vite resolver (we have to run the resolver and can't rely on the resolve setting alone due to packages like vite-tsconfig-paths), however even then we can have relative paths being resolvable to different files based on wether they were rebased or not (e.g. when an image with the same filename exists in two different paths).

So ultimately we settled on extending the already existing blocklist (which we have taken from the Vite implementation) for now.

Test plan

• Added unit test and it was tested with the Vite playground.

[ArnaudBarre]

Could the tailwind plugin skip the rebasing all together? It seems this is something that should be done by Vite core and not Tailwind. What's the need that made you add this? (I think we already discuss this but I don't remember the reason)

[philipp-spiess]

@ArnaudBarre

Could the tailwind plugin skip the rebasing all together? It seems this is something that should be done by Vite core and not Tailwind. What's the need that made you add this? (I think we already discuss this but I don't remember the reason)

The reason we need to rebase is that we do @import resolving in pre-phase so the information about where the CSS file was located is gone by the time Vite gets it :/ And since the transformers are string => string, I don't think there's any type of meta information we could pass with the transformation step so that Vite knows that some chunk of the content comes from different files.

What we did is inline the rebasing logic from Vite but since Vite seems to resolve filenames before it does the rebasing (or maybe while it does that?) it still works slightly differently.