fix(optimizer): use correct default install state path for yarn PnP

[smeng9]

Fix #19118 for the yarn's default config. Main reason is if it can't find the file, it will use empty string to generate the hash, causing the result to be the same every time.

For yarn's custom config https://yarnpkg.com/configuration/yarnrc#installStatePath we probably need a different PR.

Also are we still going to support yarn 2.4 for optimize deps? Do we have a compatibility chart for vite version vs different package manger's version?
https://github.com/yarnpkg/berry/blob/93a56643ba3c813a87920dcf75c644eaf3b38e6f/CHANGELOG.md?plain=1#L392

[bluwy]

Good catch. It's also showing up as install-state.gz for me.

[bluwy]

For yarn's custom config yarnpkg.com/configuration/yarnrc#installStatePath we probably need a different PR.

Maybe it's also possible for us to use a different file to detect? From https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored, we could also use .pnp.js or .pnp.cjs I think.

Also are we still going to support yarn 2.4 for optimize deps?

Ideally I think we should support all versions if it's not too hard to do so. Otherwise I think it's also fine for Vite to not support very old package managers. We don't really test against or track compatibility with different package managers.

[smeng9]

Hi @bluwy ,

Maybe it's also possible for us to use a different file to detect? From https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored, we could also use .pnp.js or .pnp.cjs I think.

I have applied your suggestion to check for .pnp.cjs/.pnp.js file so we don't need to deal with custom installStatePath

We don't really test against or track compatibility with different package managers.

It's not hard to add for .pnp.js for yarn v2 this time (https://yarnpkg.com/advanced/changelog#breaking-changes), but the order of files gets checked matters. .pnp.js should be checked after but not before checking the existence of .pnp.cjs https://yarnpkg.com/advanced/changelog#major-changes as the old file is not removed when updating yarn. Otherwise vite will never re-run the pre-bundle step if the unused file gets left on the disk after upgrading yarn from 2 directly to 4.

However I think probably in next major version release of vite we can specify supported package managers versions through package.json engines field for yarn https://endoflife.date/yarn and pnpm https://endoflife.date/pnpm so we no longer need to deal with edge cases like this.

[smeng9]

I guess the failing test is flaky, need to rerun.

[smeng9]

Switched back to calling yarn to get installStatePath, and if yarn is not installed will use default installStatePath location

[bluwy]

Is there a reason to switch back to that. I don't think we can afford calling execSync when importing Vite, especially if the user don't use yarn either. I think the .pnp.cjs and .pnp.js was fine though

Otherwise vite will never re-run the pre-bundle step if the unused file gets left on the disk after upgrading yarn from 2 directly to 4.

I don't think we should worry about this. Shouldn't the user remove the .pnp.js themselves ultimately? Assuming it's pretty much a dormant file.

If all else doesn't work, I think we can fallback to yarn.lock still as that's the previous behaviour.

[smeng9]

@bluwy Reverted back to using .pnp.js/.pnp.cjs file.