perf(resolve): improve package.json resolve speed

[bluwy]

Description

Should fix #8850, my benchmarks were based on on the issue's repro.

This PR bring 1.5-4x resolve speed for resolving modules that heavily rely on resolving package.json. We only use the resolve package to resolve dep package.json files, I've implemented a simpler logic for it specifically, extracted from vitefu, which has been used by many frameworks so far.

This simpler logic is more straight-forward and prevents the use of errors + try/catch. It also supports yarn pnp. (fun fact: yarn pnp patches the resolve package by default)

Additional context

It would be easier to review by each commit.

Before merging this, it might be a good idea to run ecosystem-ci.

Here are the cpuprofiles: https://gist.github.com/bluwy/19c6c3ec6fc3479ffa5e679b4c61344e

The resolve dep is not removed yet. There's one more place that needs to be fixed before doing so, the work is tracked at #11410. This shouldn't affect anything though.

---

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 PR Title 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.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[bluwy]

I had to refactor this function, since it's incorrectly using resolvePackageData and looks unnecessarily complex 🤔 What happens is that this function gets the nearest package.json, and loads the PackageData. And the new changes does the same too.

In the old changes, it manually walks /User/foo/project, create a possiblePkgIds of ['/User/foo/project', '/User/foo', '/User'], and then try to resolve the package.json in those directories. So resolvePackageData would receive absolute paths instead of bare imports which doesn't work with this refactor.

[sun0day]

Nice work!

[patak-dev]

Incredible work 🔥

Changes look good to me, thanks for breaking them down into simpler commits.

It feels a bit big to include in a patch. But it is tempting to do so. If we don't, we could start the 4.3 beta soon after we give some time to 4.2 to stabilize.

[patak-dev]

/ecosystem-ci run

[vite-ecosystem-ci]

📝 Ran ecosystem CI: Open

suite	result
astro	✅ success
histoire	❌ failure
iles	✅ success
ladle	✅ success
laravel	✅ success
marko	✅ success
nuxt	❌ failure
previewjs	✅ success
qwik	❌ failure
rakkas	✅ success
sveltekit	✅ success
vite-plugin-ssr	✅ success
vite-plugin-react	✅ success
vite-plugin-react-pages	✅ success
vite-plugin-react-swc	✅ success
vite-plugin-svelte	✅ success
vite-plugin-vue	✅ success
vite-setup-catalogue	✅ success
vitepress	✅ success
vitest	✅ success
windicss	✅ success

[patak-dev]

The same projects are failing compared to main (same error in Nuxt). I think we should merge and release tomorrow as 4.2.1 so we can build on top of this PR without waiting for 4.3.

[dominikg]

I like the simple approach this has 👍

[Liknox]

Looks amazing🔥. I think we should implement this performance improving!

[brillout]

A little late to the party, but LGTM. (Also 👍 to get it out in the field sooner rather than lather.) Neat PR 🔥.

[bartlomieju]

Commenting at the request of @bluwy - LGTM and shouldn't be a blocker in any way for Deno plugin.