pnpm for Gutenberg #74309
Replies: 6 comments 4 replies
-
|
If its passing, why don't you move out of Draft? |
Beta Was this translation helpful? Give feedback.
-
|
This needs to be coordinated with Core. Especially after my PR here WordPress/wordpress-develop#10638 Not in disagreement but this likely need to be a make/core proposal for more visibility and coordination with Core IMO. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with what @youknowriad said, I'd expect Core to switch to pnpm if and when Gutenberg does. There's value in the two projects being aligned. It's important to understand how that impacts Core and what changes would be necessary there. It may signal to the WordPress community a preference for pnpm. This could start as a discussion topic at a
I'd like to see data about this for the relevant projects. How much faster? How much smaller on disk? How many dependency issues are there and what's the impact? I'd also like to know how much of an impact it has on CI. If CI for Gutenberg and Core can get a significant speed-up from faster and smaller installation, that's a compelling motivation to switch.
Will you explain the reasoning behind this guideline? For a project like Gutenberg, I disagree. Gutenberg publishes libraries, and when libraries use exact versions it tends to cause package duplication and inconvenience for downstream consumers. For applications (not published as libraries), exact versions do have benefits. |
Beta Was this translation helpful? Give feedback.
-
|
Security features are another factor I'd consider in weighing |
Beta Was this translation helpful? Give feedback.
-
|
Surely it must be coordinated with Core. But I only see two caveats.
So yes, It would be a great idea to do some coordination with Core, but not mandatory to be synchronized. If possible |
Beta Was this translation helpful? Give feedback.
-
|
While it is good to coordinate this with Core, the problem we are trying to solve here is to have the published packages in a good state, without missing dependencies, etc. IIRC, Core doesn't publish any packages to npm and may not need to handle the issues we face in Gutenberg. So, it's fine to do it in Gutenberg, and then if possible/feasible, we can use pnpm in Core as well. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I've been exploring using
pnpmas the package manager for the Gutenberg monorepo. The proof-of-concept PR - #74135 demonstrates a full conversion with all tests passing and everything building correctly.Because switching package managers is a significant change that touches many files, this discussion outlines a plan to break it into smaller, reviewable chunks.
Previous Efforts
Why pnpm?
pnpm offers faster installs, efficient disk usage through content-addressable storage, and stricter dependency resolution that catches missing dependencies early. We at Jetpack often have to deal with dependency issues for
@wordpress/*packages. Using pnpm will prevent many such issues.Takeaways from the POC
/storybookshould be a workspace to avoid the need for all its dependencies in the root package.jsonMigration Strategy
The migration is split into smaller, reviewable chunks:
Incremental PRs: Fix packages with missing peer dependencies or conflicting versions in separate PRs. These improvements benefit the monorepo regardless of the final switch to pnpm. It can be done by picking the chunks from the POC PR.
Final Switch PR: Once all packages are ready, a final PR will:
package.jsonfiles withworkspace:protocol for local dependenciespnpm-lock.yamllockfilepnpm-workspace.yamlconfigurationGuidelines
When making changes, keep these in mind:
Pin dependencies to exact versions - Avoid caret (^) or tilde (~) ranges. This ensures a more efficient and predictable dependency tree.namefield - Some workspaces in/routesare missing this, which is required for pnpm to work correctly.CI Considerations
Some workflows compare against previous builds stored with npm. These will need baseline updates after the switch:
.github/workflows/bundle-size.yml- Compares bundle sizes against trunk.github/workflows/performance.yml- Compares performance metrics against trunkThese workflows are expected to fail for the final PR until baselines are updated post-merge.
Help Wanted
Looking for reviewers to help with the incremental PRs.
CC: @jsnajdr @aduth @sirreal @nerrad
Beta Was this translation helpful? Give feedback.
All reactions