[core] Make pnpm version permissive #529
Conversation
| "webpack-cli": "^5.1.4", | ||
| "yargs": "^17.7.2" | ||
| }, | ||
| "packageManager": "[email protected]", |
There was a problem hiding this comment.
pnpm >=9.2.0 removed the strictness so this should still remain permissive as long as a version matching that is used
Netlify deploy preview |
There was a problem hiding this comment.
This change seems to contradict mui/mui-public#157, so to figure out what's the best path forward, I doubt it makes sense to operate with two different solutions (between the different MUI repositories) on this.
| "packageManager": "[email protected]", | ||
| "engines": { | ||
| "pnpm": "9.6.0" | ||
| "pnpm": "^9.0.0" |
There was a problem hiding this comment.
Per mui/toolpad#3396 (comment), is this right? Unlike with node (I agree there), packageManager guarantees us a single pnpm version installed. https://github.com/nodejs/corepack, so it seems to be that we should revert.
There was a problem hiding this comment.
The Twitter thread in the first post has the reasoning. Restricting the major version makes sense, but I don't see why patch/minors matter when the same major works correctly, it makes it annoying to work on the project by constantly needing to ensure the pnpm version is synchronized. Unless there's a recommended tool to make that automatic
There was a problem hiding this comment.
Unless there's a recommended tool to make that automatic
I believe corepack, built-in into Node.js, does this automatically (it works automatically on my env)
As I understand it, the advantage is that it makes the scripts fail as soon as the version of pnpm doesn't match, (so when corepack is not configured correctly). The early fail avoids weird bugs that only reproduce when not using the same pnpm version locally as in the CI.
There was a problem hiding this comment.
I did try corepack a ~month ago after the change, but it was causing issues again recently for some reason (it's still listed as experimental). I figured this wasn't worth the trouble to deal with because it wastes time trying to work around it; having the minors/patches of your pnpm version be different locally won't cause issues in practice.
It's similar to transitive deps being permissive with the caret versioning of a major, which in practice works fine until a specific bug comes up and an update is necessary, which is rare - especially with a package manager.
There was a problem hiding this comment.
Interesting, if corepack fails to function correctly, it's pain indeed 🙃. Not sure what we should do then.
cc @Janpot for awareness that not all community contributors might have corepack working.
There was a problem hiding this comment.
For the record, I haven't had any issues with Corepack so far
There was a problem hiding this comment.
Oh well: nodejs/package-maintenance#606, no more plans for corepack enabled by default in node 🙃
There was a problem hiding this comment.
As far as I understand the project will still live, but the plan is to not include it in Node distribution.
There was a problem hiding this comment.
Agree, it's still ok, but it would have been so nice for it to "just work".
There was a problem hiding this comment.
It should be fine to loosen the engines.pnpm restriction to the first one that supports the packageManager field. i.e. >=9.7 + add manage-package-manager-versions.
michaldudak
added
the
scope: code-infra
oliviertassinari
added
internal
5 participants
https://x.com/rickhanlonii/status/1790015586744795353
Avoids: