perf(resolve): refactor package.json handling for deep imports

[bluwy]

Description

Partial revert of #5665. That PR was not exports friendly and we had to fix it in #10371, but it mixes both "root" package.json and "nearest" package.json, which needs to be handled separately.

This PR refactors in a way that pkg passed to resolveDeepImport and resolvePackageEntry is always the "root" package.json. If further down the chain a resolve logic needs the "nearest" package.json, they can resolve it themselves.

This change shouldn't break resolvePackageEntry (since that's root import only), but changes resolveDeepImport slightly, where:

• If "root" package.json has no exports field, the browser field (if available) will be derive from the "root" package.json (now), instead of the "nearest" package.json (before)

I think the above is a bug fix though.

More details about `browser`

According to https://github.com/defunctzombie/package-browser-field-spec#alternate-main---basic:

All paths for browser fields are relative to the package.json file location (and usually project root as a result).

It implies that package.json other than "root" should be checked too, but if we respect it, that means we have to check all package.json that's part of the current file path, which is a lot of work even if the browser field was never used.

I think it's fine for now to check the browser field based on "root" package.json only as that's the more common case.

Additional context

No benchmarks 😬 But I noticed this optimization as we're consistently trying to resolve package.json for long deep import paths due to:

vite/packages/vite/src/node/plugins/resolve.ts

Lines 717 to 725 in 535c8c5

	const nearestPkgId = [...possiblePkgIds].reverse().find((pkgId) => {
	nearestPkg = resolvePackageData(
	pkgId,
	basedir,
	preserveSymlinks,
	packageCache,
	)!
	return nearestPkg
	})!

---

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.

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[patak-cat]

/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	❌ failure
vitest	✅ success
windicss	✅ success

[patak-cat]

Qwik, Nuxt, and Histoire are also currently failing on main (same errors).

But Vitepress against main was successful, so there may be a regression for it 👀

[bluwy]

I ran the VitePress test locally, and I can get the same error, but it's not always reproducible. When they do fail, I can confirm that the VitePress page has an empty <div id="app"></div> which would fail the test. But I'm not sure how that happens.

I can confirm when running some repros that this PR improves the resolve speed slightly, so it's not slowing down the tests that causes it to timeout. Not really sure what to do here though, we could maybe test again when we start the minor.

I'm guessing it's some sort of race condition, since running that failing test directly via pnpm test-init is less likely to cause the fail.

[patak-cat]

cc @brc-dd in case you have some time to help us debugging this in VitePress before 4.3

[brc-dd]

Yeah, I'll look into this, it's probably just a flaky test IG 👀 Even in our repo, we sometimes have to rerun jobs.

[brc-dd]

@patak-dev Hey, can you try rerunning the CI for vitepress and see if it's consistently failing for a specific test? If it's random or some race condition, then feel free to go ahead with the PR, I don't think vite has anything to do with that.

Ah, ok nvm. You guys already triggered it 3 times.

[brc-dd]

Seems like some issue with one of our deps, appears to be working after bumping them: https://github.com/brc-dd/vite-ecosystem-ci/actions/runs/4448482529/attempts/1, https://github.com/brc-dd/vite-ecosystem-ci/actions/runs/4448586970/jobs/7811590602

[patak-cat]

/ecosystem-ci run vitepress

[vite-ecosystem-ci]

📝 Ran ecosystem CI: Open

suite	result
vitepress	❌ failure

[brc-dd]

Failed 🫠

[patak-cat]

/ecosystem-ci run vitepress

[vite-ecosystem-ci]

📝 Ran ecosystem CI: Open

suite	result
vitepress	❌ failure

[bluwy]

Yeah it looks like something in this PR is causing it to happen more frequently, but I can't tell where. Thanks for looking into this though @brc-dd!

[patak-cat]

/ecosystem-ci run vitepress

[vite-ecosystem-ci]

📝 Ran ecosystem CI: Open

suite	result
vitepress	✅ success

[patak-cat]

/ecosystem-ci run vitepress

[vite-ecosystem-ci]

📝 Ran ecosystem CI: Open

suite	result
vitepress	✅ success