build: Switch to devEngines.packageManager

[mnonnenmacher]

Define the pnpm version to using the new devEngines.packageManager 1 property instead of packageManager. As for dependencies, use a pinned version instead of a version range.

[sschuberth]

This should not be needed anymore with my changes in #5015. Do you think the changes are still useful? Is the packageManager field officially deprecated?

[sschuberth]

In any case, I think we should link to https://docs.npmjs.com/cli/v11/configuring-npm/package-json#devengines to make clear that devEngines.packageManager is not a PNPM-specific field.

[mnonnenmacher]

This should not be needed anymore with my changes in #5015. Do you think the changes are still useful? Is the packageManager field officially deprecated?

Yes, several options related to the packageManager option were removed and they call it legacy: https://pnpm.io/blog/releases/11.0#other-removals

Also, the error message I got in the other PR sounded like corepack would now require the new option to install the correct pnpm version which might be relevant again for local builds after the next upgrade.

[mnonnenmacher]

In any case, I think we should link to https://docs.npmjs.com/cli/v11/configuring-npm/package-json#devengines to make clear that devEngines.packageManager is not a PNPM-specific field.

I'd rather link the pnpm docs than the npm docs as they also better explain the packageManager option.

[sschuberth]

Yes, several options related to the packageManager option were removed and they call it legacy: https://pnpm.io/blog/releases/11.0#other-removals

But that's all PNPM-specific docs. To me, that does not count here.

like corepack would now require the new option to install the correct pnpm version which might be relevant again for local builds after the next upgrade.

I don't think that's the case.

[mnonnenmacher]

Yes, several options related to the packageManager option were removed and they call it legacy: https://pnpm.io/blog/releases/11.0#other-removals

But that's all PNPM-specific docs. To me, that does not count here.

But we use pnpm not npm, so it matters which options are supported by pnpm. Also, it seems that npm never supported packageManager, only corepack (and pnpm) did.

like corepack would now require the new option to install the correct pnpm version which might be relevant again for local builds after the next upgrade.

I don't think that's the case.

This was the error message:

Error: This project is configured to use 10.33.2 of pnpm. Your current pnpm is v11.0.8
Corepack invoked pnpm with this version, and pnpm does not switch versions when running under corepack.
Align the "packageManager" field in package.json with "devEngines.packageManager", or invoke pnpm directly (without corepack) so it can switch versions automatically.
If you want to bypass this version check, you can set the "pmOnFail" configuration to "warn" or "ignore" (e.g. via --pm-on-fail=ignore). If using "devEngines.packageManager", you can set its "onFail" to "warn" or "ignore"

Although I don't understand why this happens, because corepack should have installed the correct version in the first place based on the packageManager property instead of 11.0.8.

I went down the rabbit hole a bit too far, but my conclusion is that currently it would be best to set both fields and keep them aligned, because pnpm is moving to the new property while corepack still seems to rely on the old one. But I also don't know if Renovate properly supports having both. I'll just turn this into a draft for now as long as there is no issue with only having packageManager. But it sounds like with some future release pnpm might require that only the new property is used.

Some references:
Original proposal: openjs-foundation/package-metadata-interoperability-working-group#15
Current spec: https://github.com/openjs-foundation/package-metadata-interoperability-working-group/blob/main/devengines-field-proposal.md
Reason why pnpm does currently not warn if both are aligned: pnpm/pnpm#11301

[sschuberth]

Also, it seems that npm never supported packageManager, only corepack (and pnpm) did.

Well, Node.js ships with both npm and corepack, and corepack supports npm. If you launch npm, that's actually just a shim running corepack. In that sense, no Node.js package manager itself supports packageManager, but only corepack does.

This was the error message:

Yes, that's the same I got before #5015.

Although I don't understand why this happens, because corepack should have installed the correct version in the first place based on the packageManager property instead of 11.0.8.

Could be that there was a glitch in pnpm version before 11.0.2: "Fixed packageManagerDependencies going stale when pnpm is invoked through corepack". And so upgrading our project to use 11.0.8 maybe fixed it.

[sschuberth]

I guess it'd work now if we bump the versions to 11.0.9...

[mnonnenmacher]

I guess it'd work now if we bump the versions to 11.0.9...

I think #5037 is the required fix when using corepack. Maybe we always used the wrong version in the past and the version check just got more strict with pnpm 11.

[sschuberth]

@mnonnenmacher, how should we proceed with his now?

[sschuberth]

@mnonnenmacher, how should we proceed with his now?

@mnonnenmacher, I propose to close this unmerged as it seems to work without this now (also after several PNPM updates), and this avoids us to maintain the PNPM version in more places.

[mnonnenmacher]

@mnonnenmacher, how should we proceed with his now?

@mnonnenmacher, I propose to close this unmerged as it seems to work without this now (also after several PNPM updates), and this avoids us to maintain the PNPM version in more places.

I would still like to merge this as for PNPM 11 this is the correct configuration, it's also used by pnpm init instead of packageManager: https://pnpm.io/blog/releases/11.0#other-notable-changes

The only thing holding me back from marking this ready for review again was that it is unclear if Renovate supports devEngines.packageManager because there is this open ticket and I did not have time to check if it works anyway:
renovatebot/renovate#38067

And what do you mean by "maintain the PNPM version in more places"?

[sschuberth]

And what do you mean by "maintain the PNPM version in more places"?

Sorry, it seems I misremembered that this would also keep the upper-level "packageManager": "pnpm@11.0.8",.