Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[core] Make pnpm version permissive #529

Merged
merged 4 commits into from
Aug 6, 2024
Merged

Conversation

atomiks
Copy link
Contributor

@atomiks atomiks commented Aug 4, 2024

@atomiks atomiks added the core Infrastructure work going on behind the scenes label Aug 4, 2024
@@ -164,7 +164,7 @@
},
"packageManager": "pnpm@9.6.0",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pnpm >=9.2.0 removed the strictness so this should still remain permissive as long as a version matching that is used

@mui-bot
Copy link

mui-bot commented Aug 4, 2024

Netlify deploy preview

https://deploy-preview-529--base-ui.netlify.app/

Generated by 🚫 dangerJS against 5bece3f

@atomiks atomiks merged commit 071e4f1 into mui:master Aug 6, 2024
17 of 18 checks passed
Copy link
Member

@oliviertassinari oliviertassinari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

"pnpm": "9.6.0"
"pnpm": "^9.0.0"
Copy link
Member

@oliviertassinari oliviertassinari Aug 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@oliviertassinari oliviertassinari Aug 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@oliviertassinari oliviertassinari Aug 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the record, I haven't had any issues with Corepack so far

Copy link
Member

@oliviertassinari oliviertassinari Aug 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh well: nodejs/package-maintenance#606, no more plans for corepack enabled by default in node 🙃

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I understand the project will still live, but the plan is to not include it in Node distribution.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, it's still ok, but it would have been so nice for it to "just work".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@atomiks atomiks deleted the fix/permissive-pnpm branch August 6, 2024 23:13
@oliviertassinari oliviertassinari added the scope: code-infra Specific to the code-infra product label Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Infrastructure work going on behind the scenes scope: code-infra Specific to the code-infra product
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants