New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update pnpm version detection logic #11445
Update pnpm version detection logic #11445
Conversation
🦋 Changeset detectedLatest commit: 89e22e2 The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
618ddff
to
1ccdded
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At a single read-through, this looks good to me. I can't dive deeper in review right now, though. We'll want to manually test many scenarios in the build container before rolling this change there, for sure.
…version-to-determine-pnpm-version
…version-to-determine-pnpm-version
…version-to-determine-pnpm-version
switch (true) { | ||
case cliType === 'yarn' && !env.YARN_NODE_LINKER: | ||
return { ...overrides, yarnNodeLinker: 'node-modules' }; | ||
case alreadyInPath(overrides.path ?? ''): | ||
return { | ||
detectedLockfile: undefined, | ||
detectedPackageManager: undefined, | ||
path: undefined, | ||
yarnNodeLinker: undefined, | ||
}; | ||
default: | ||
return { ...overrides, yarnNodeLinker: undefined }; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion (non-blocking): ifs over switches?
The switch-true pattern is harder to understand than the equivalent if-return or if-else, in my opinion. I suggest changing this, but it's up to you.
…version-to-determine-pnpm-version
…version-to-determine-pnpm-version
…version-to-determine-pnpm-version
…version-to-determine-pnpm-version
…version-to-determine-pnpm-version
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @vercel/build-utils@8.1.0 ### Minor Changes - Update pnpm version detection logic ([#11445](#11445)) Add support for pnpm 9 ## vercel@34.1.11 ### Patch Changes - Updated dependencies \[[`5014b1e82`](5014b1e), [`18d1703d5`](18d1703), [`e87d4c14d`](e87d4c1), [`bc5fd4115`](bc5fd41)]: - @vercel/build-utils@8.1.0 - @vercel/next@4.2.10 - @vercel/redwood@2.0.9 - @vercel/remix-builder@2.1.6 - @vercel/node@3.1.1 - @vercel/static-build@2.5.5 ## @vercel/client@13.2.3 ### Patch Changes - Updated dependencies \[[`5014b1e82`](5014b1e)]: - @vercel/build-utils@8.1.0 ## @vercel/gatsby-plugin-vercel-builder@2.0.27 ### Patch Changes - Updated dependencies \[[`5014b1e82`](5014b1e)]: - @vercel/build-utils@8.1.0 ## @vercel/next@4.2.10 ### Patch Changes - skip action rewrites for RSC requests ([#11576](#11576)) - Bump `@vercel/nft@0.27.0` ([#11580](#11580)) ## @vercel/node@3.1.1 ### Patch Changes - Bump `@vercel/nft@0.27.0` ([#11580](#11580)) - Updated dependencies \[[`5014b1e82`](5014b1e)]: - @vercel/build-utils@8.1.0 ## @vercel/redwood@2.0.9 ### Patch Changes - Bump `@vercel/nft@0.27.0` ([#11580](#11580)) ## @vercel/remix-builder@2.1.6 ### Patch Changes - Bump `@vercel/nft@0.27.0` ([#11580](#11580)) - Update `@remix-run/dev` fork to v2.9.2-patch.2 ([#11582](#11582)) ## @vercel/static-build@2.5.5 ### Patch Changes - Updated dependencies \[]: - @vercel/gatsby-plugin-vercel-builder@2.0.27 ## @vercel-internals/types@1.0.32 ### Patch Changes - Updated dependencies \[[`5014b1e82`](5014b1e)]: - @vercel/build-utils@8.1.0 Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
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 thePATH
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 thePATH
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
andpnpm 8
changes requested, with no changes yet to implementpnpm 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.