Open mmkal opened 9 months ago
The advantage is that this installs the "executable" version of pnpm, which is bundled with node.js using vercel/pkg
. The "executable" version of pnpm is a bit faster and can run on any version of node.js.
Is this really true? Isn't this a flag https://github.com/pnpm/action-setup/tree/v2#standalone ?
Surely, an advantage over corepack
is that the action already takes care of store prune, see https://github.com/pnpm/action-setup#use-cache-to-reduce-installation-time.
One downside is that corepack is still marked as experimental: https://nodejs.org/docs/latest-v20.x/api/corepack.html
@segevfiner yes, it is turned off by default at the moment.
There is nothing wrong with corepack. In our docs we actually recommend corepack for all CIs except Github actions: https://pnpm.io/continuous-integration. But there is nothing wrong with using corepack instead of this action.
Edit: as of pnpm/action-setup@v4
, the error described below is surfaced proactively to users with suggestions how to fix the configuration.
One downside of pnpm/action-setup
vs corepack enable
is that it can lead to ERR_PNPM_BAD_PM_VERSION
failures on pnpm install
when using the packageManager
field in package.json
:
pnpm/action-setup
step with version: 'latest'
packageManager
in package.json
with an old version eg. "packageManager": "pnpm@9.0.3"
ERR_PNPM_BAD_PM_VERSION
error below on pnpm install
on CI 💥$ pnpm install
 ERR_PNPM_BAD_PM_VERSION  This project is configured to use v9.0.3 of pnpm. Your current pnpm is v9.0.4
If you want to bypass this version check, you can set the "package-manager-strict" configuration to "false" or set the "COREPACK_ENABLE_STRICT" environment variable to "0"
Remove the version: 'latest'
config to enable packageManager
support:
- uses: pnpm/action-setup@v3
with:
- version: 'latest'
Switch pnpm/action-setup
to corepack enable
to resolve this error:
- - uses: pnpm/action-setup@v3
- with:
- version: 'latest'
+ - run: corepack enable
Always keep packageManager
in package.json
immediately up to date, eg. using a bot like Renovate bot
@zkochan because of the ERR_PNPM_BAD_PM_VERSION
error above, maybe pnpm/action-setup
should be removed as the recommendation for GitHub Actions?
(to avoid users running into this footgun, especially since packageManager
is the recommended way of setting a pnpm version on some platforms like Netlify)
Or, alternatively, if pnpm/action-setup
would automatically respect the version in packageManager
in package.json
, that would be another option (as a feature request to pnpm/action-setup
).
Doesn't it already have a feature to look at packageManager
if you don't specify version
? Check the README, I remember I configured it like this.
Indeed, I somehow missed this!
As per the pnpm/action-setup
docs about the version
option, to use the packageManager
version, you can just omit the version
config:
version
Version of pnpm to install.
Optional when there is a
packageManager
field in thepackage.json
.
However, this should probably error in the action when packageManager
is set and version
is specified.
I'll create an issue
Ok I ended up creating a PR for this instead - to throw an error if multiple versions of pnpm are specified:
Similar to #30 - I am wondering if there's an advantage to using this vs just running
corepack enable
, which as far as I understand, will instruct node itself to download and installpnpm
, and will respect thepackageManager
field in package.json.I'm doing this in my expect-type repo (permalink) and it seems to be working - is there a downside that you know of?