Use pnpm@9 for lockfile >= 9.0 #9668
Conversation
tusbar
force-pushed
the
support-pnpm-lockfile-9
branch
2 times, most recently
from
608a521
to
f8c0232
Compare
| if pnpm_lockfile_version(pnpm_lock).to_f >= 6.0 | ||
| if pnpm_lockfile_version(pnpm_lock).to_f >= 9.0 | ||
| 9 | ||
| elsif pnpm_lockfile_version(pnpm_lock).to_f >= 6.0 | ||
| 8 | ||
| elsif pnpm_lockfile_version(pnpm_lock).to_f >= 5.4 | ||
| 7 |
There was a problem hiding this comment.
It might be better to invert the checks:
pnpm_version = pnpm_lockfile_version(pnpm_lock).to_f;
if pnpm_version < 5.4
6
elsif pnpm_version < 6
7
elsif pnpm_version < 9
8
else
pnpm_version.to_i
end
Then you'll likely never have to fix it again. ;). Just be done fixing it. @jeffwidman @bdragon @tusbar
It seems quite likely that from now on, for future versions of pnpm, it will be safe to install the same major version as the lockfile indicates (kinda wild to even have to say that 😆 ).
thavaahariharangit
force-pushed
the
support-pnpm-lockfile-9
branch
from
f8c0232
to
176339f
Compare
|
🥳 Is pnpm 9 supported at github immediately or are we waiting on a release? |
|
@robaiken – although lockfiles v9.0 can be parsed, pnpm 9 won’t be used as long as this is not released. Lockfiles will get re-generated using v6.0 format. |
|
We deploy Deploys are invisible to the public, but we often follow a deploy-then-merge strategy, and if we don't, we generally merge a couple of low-risk PR's and then do a fast-follow deploy which will pick up the whole 🚂 . So this is already live on GitHub.com. If you're still seeing issues with the GitHub.com hosted version of |
, then please file an issue or better yet raise a PR.
Related: #9522