The previous logic was checking for the env var `ENABLE_EXPERIMENTAL_COREPACK` to determine if corepack was being used by a project. However, this value only means that the build system should consider corepack, not that it's actively being used.
We need to check that flag AND the existence of a `packageManager` property in the project's `package.json`.
Both `pnpm@6` and `pnpm@7` can parse lockfile versions `5.3` and `5.4`, but if there's a mismatch, `pnpm` will output a warning saying so. In order to prevent confusing warnings from being displayed to the user, this PR aligns the pnpm version with the exact lockfile verison.
It also adds a debug log to show which package manager version was determined based on the lockfile version.
The code we use to detect the version of `pnpm` based on lockfiles is hard to follow. It doesn't pick and executable, it instead of *sometimes* overrides the `PATH` for these utilities with a prepended alternate path.
This means that there is no one single place where we definitively specify which version of `pnpm` that is used, so much as *hope* that the `PATH` has the correct version on it. I don't know that we *can* specify an executable outside of the build container, and it's unclear, since this is a package, whether this utility is used outside of a build container setting.
In this pull request I cleaned up the code and updated the logic to include the `pnpm 7` and `pnpm 8` changes requested, with no changes yet to implement `pnpm 9`.
It's possible that we want to rewrite this detection logic from scratch to avoid this roundabout way of "finding" the executable, but I haven't done that here.
To use this outside of CLI we want a way to suppress the `console.log`s in `getEnvForPackageManager`.
For achieving this, we introduce a new helper `getPathForPackageManager()` which contains the core logic.
Best to review commit by commit + hide whitespace.
**X-Ref**
- [Internal Context](https://vercel.slack.com/archives/C03F2CMNGKG/p1701970097725689)
This PR fixes a bug where corepack (#7871) was not correctly setup because the lockfile autodetection and node version autodetection was overriding the PATH.
It also fixes a bug where the log output was printed twice because we incorrectly prepended the PATH twice.
### Related Issues
Fixes pnpm 7 support. Now uses a yarn installed version and drops an unnecessary check for node version.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### Tests
- [ ] The code changed/added as part of this PR has been covered with tests
- [ ] All tests pass locally with `yarn test-unit`
#### Code Review
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
### Related Issues
Adds support for `pnpm@7` using a similar lock file detection and path setting method that `npm@7` uses
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### Tests
- [x] The code changed/added as part of this PR has been covered with tests
- [x] All tests pass locally with `yarn test-unit`
#### Code Review
- [x] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
