fix(resolve): fix resolve cache to consider conditions and more

[hi-ogawa]

Description

• closes resolve.conditions not working reliably on custom environment #18222
• fixes pluginContainer.resolveId(..., { ssr: true }) works differently from ssrLoadModule resolution for "module" entry/exports #16631 too

I simply expanded the cache key of "resolved cache", but I'm not sure if just concatenating everything is the best way in terms of performance.

todo

• measure perf
  • chore: add vite-perf-resolve-cache hi-ogawa/reproductions#41

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[hi-ogawa]

I created a bench script with server.pluginContainer.resolveId("some-package") loop. hi-ogawa/reproductions#41

Negative perf impact on resolvePackageEntry seems clear, but I'm not sure if there's a way to mitigate this. Can this per hit be considered acceptable?

cpuprofile viz

beta: CPU.20241009.130606.40833.0.001.cpuprofile

this pr: CPU.20241009.130349.39525.0.001.cpuprofile

[patak-dev]

I think we should move forward with this fix for now. In the future, we could explore moving the resolve cache to the environment instance and pass it to the resolve plugin options.

[hi-ogawa]

Maybe a simpler approach to split the cache for environment is to split PackageCache, which I think is currently shared at base ResolvedConfig.packageCache.

I was testing css @import which uses style condition and I thought it would have the same issue, but it didn't on main. This made me wonder it's because css resolver doesn't use packageCache.

[sapphi-red]

I tested removing the whole resolvedCache but it seems that degrades perf by ~10%. It seems we need to keep this.

I also tested this branch with #16631. The issue is now fixed and server.ssrLoadModule resolves to dist/emotion-react.cjs.mjs even after server.pluginContainer.resolveId is called.

[hi-ogawa]

I was thinking we can instantiate a dedicated config.packageCache for each environment by proxying it here. Build is working but dev seems to have some issues. Is this approach supposed to work or packageCache should be still singleton?

vite/packages/vite/src/node/baseEnvironment.ts

Lines 67 to 80 in 25868f2

	this.config = new Proxy(
	options as ResolvedConfig & ResolvedEnvironmentOptions,
	{
	get: (target, prop: keyof ResolvedConfig) => {
	if (prop === 'logger') {
	return this.logger
	}
	if (prop in target) {
	return this._options[prop as keyof ResolvedEnvironmentOptions]
	}
	return this._topLevelConfig[prop]
	},
	},
	)

[hi-ogawa]

I made environment.config.packageCache approach in a separate PR #18319. This seems like a sensible solution, but I need to double check if we can replace currently usages of config.packageCache nicely.

[patak-dev]

As proposed by @hi-ogawa in the linked PR, we could move forward with this one to get the fix in, and then rework in a future PR to optimize it. @sapphi-red I'll let you merge it if you are ok with this