Run & review this pull request in StackBlitz Codeflow.

Interesting, one down, one up for the benchmarks https://github.com/vitejs/vite-benchmark/actions/runs/4660951837. Maybe there is something wrong with the PR, I wouldn't expect things to be slower after it.

Another run with the same result https://github.com/vitejs/vite-benchmark/actions/runs/4664331499. @fi3ework said that there could be a 1% variance that is noise though.

I ran this locally with a project with many entires (git merge main first as the optimizer change seems to affect the timing), I'm seeing a small decrease of 290s to 283ms. Maybe it's more obvious on other OSes.

Ran twice on Windows (add a os inputs for workflow)

• https://github.com/vitejs/vite-benchmark/actions/runs/4670725178
• https://github.com/vitejs/vite-benchmark/actions/runs/4670954361

It shows FCP did get a perf gain 🤔.

I did 50 times run in Linux and it shows ~0.75% improvement of the 2.7-slow case, and almost no difference in the other case: https://github.com/vitejs/vite-benchmark/actions/runs/4682746568

If this is safe, it looks like a good optimization. We can also hold it until the next minor to keep stabilizing 4.3 and getting to users sooner.

I ran the "1000 React components" benchmark on my machine with this PR.

Babel (cold start) was 4949.9ms and SWC (cold start) was 3046.5ms.
It's a 150ms - 200ms perf gain.

I noticed that the scanner uses the same Package Cache with the normal pipeline. So the scanner's preserveSymlinks: true result might pollute the Package Cache. Then, the normal pipeline will resolve the path with preserveSymlinks: true when we expect the path to be resolved with preserveSymlinks: false.

Thanks for the review @sapphi-red. I'm no longer sure about adding the extra complexity of changing preserverSymlinks for user code only, even if we could use separate package caches. Let's close this PR for now.