Conversation
gavinxgu
force-pushed
the
guxiang/pnpm-10
branch
2 times, most recently
from
a1c50d7 to
00e3c4d
Compare
| if (!pnpmVersion || !(pnpmVersion.startsWith('8') || pnpmVersion.startsWith('9'))) { | ||
| if ( | ||
| !pnpmVersion || | ||
| !(pnpmVersion.startsWith('8') || pnpmVersion.startsWith('9') || pnpmVersion.startsWith('10')) |
There was a problem hiding this comment.
@gavinxgu Seems like '80' also startsWith('8'). Should we check for something like 8.?
There was a problem hiding this comment.
Should lockfileVersion also be changed from '6' to '6.'? However, I noticed that in the type definitions for lockfile v6, lockfileVersion is defined as string | number. In some cases, if it returns the number 6 and we apply toString(), wouldn't that cause '6.' to fail to match?
There was a problem hiding this comment.
You could parse it into a number and then do a numeric comparison for that one. I doubt that lockfileVersion will use X.Y.Z syntax -- it is probably just an integer (or maybe regular decimal).
There was a problem hiding this comment.
lockfileVersion is semver consisting of major and minor. It is the version of pnpm that first shipped the new format. The current format is 9.0, which was shippped in pnpm v9.0.0.
- Add pnpm v10 compatibility - Add multi-version pnpm testing to ensure cross-version compatibility
gavinxgu
force-pushed
the
guxiang/pnpm-10
branch
from
00e3c4d to
61172f6
Compare
| } | ||
| } | ||
|
|
||
| export const isPnpmV8 = (pnpmVersion: string): boolean => pnpmVersion.startsWith('8.'); |
There was a problem hiding this comment.
@octogonz I extracted the logic for checking pnpm version into three utility functions.
| */ | ||
| packages: Record<string, ILockfilePackage>; | ||
| } | ||
| export type ILockfile = LockfileObjectV6 | LockfileObjectV9; |
There was a problem hiding this comment.
@octogonz Because we changed to use the official lockfile type provided by pnpm, this change might be a breaking change to the return value type of the readPnpmLockfile function. P.S. However, I'm not quite sure why we previously defined our own pnpmlock file type instead of using the official one.
…5254) * [rush] Upgrade `pnpm-sync-lib` to v0.3.3 for pnpm v10 compatibility tiktok/pnpm-sync#40 tiktok/pnpm-sync#43 * Fix merge conflicts so "rush-lib" compiles again * Revert Lockfile Explorer changes, since PNPM 10 support was already implemented after this PR was started * Dynamic import `@rushstack/rush-pnpm-kit-*` packages. * Include explicit types. * Include missing eslint config, README, and LICENSE files. * Fix lint issues. * fixup! Dynamic import `@rushstack/rush-pnpm-kit-*` packages. * Dynamically import the pnpm kits in PnpmShrinkwrapFile. * Revert "Dynamically import the pnpm kits in PnpmShrinkwrapFile." This reverts commit 6ede3d3. * Lazy-load the pnpm kits in PnpmShrinkwrapFile. * Leave a note about reworking load of @rushstack/rush-pnpm-kit-*. --------- Co-authored-by: Pete Gonzalez <4673363+octogonz@users.noreply.github.com> Co-authored-by: Ian Clanton-Thuon <iclanton@users.noreply.github.com>
3 participants
Uh oh!
There was an error while loading. Please reload this page.