Catalogs Tracking Issue

[gluxon]

This is a tracking issue for the implementation of RFC: Catalogs — Shareable dependency version specifiers. All pull requests and commits related to the initial implementation of this feature will reference this issue number.

Tasks

• Support the catalog: and catalog:default specifiers.
• Support catalog:<name> specifiers.
• The pnpm add command should add catalog: specifiers if possible.
• The pnpm update command should be able to update dependencies specified through catalogs. This will likely require updating pnpm-workspace.yaml.
• There will likely need to be a lockfileVersion increase in the pnpm-lock.yaml file.
  • Update: I think this won't be required after all.
• Show an error for recursive catalog references.

Improvements

These would be good to have, but not required.

• Persist comments and white-space when updating pnpm-workspace.yaml. We don't do this for package.yaml either, but hopefully we can carry over whatever solution lands there.

Tests

• Changing a catalog entry in pnpm-workspace.yaml causes the lock file to not be up to date.
• Catalog specifiers error out if used by external dependencies.

Rollout

• Allow users to create a best-effort default catalog. We could consider an internal pnpm catalog migrate command or an external pnpm dlx @pnpm/catalog-migrate command.
• Test common automated dependency mechanisms such as Dependabot and Mend Renovate to track whether they can support catalog updates.
• Update docs to explain how the catalog works.
• Consider a more publicly facing announcement that explains what problems catalogs solve.

[JasonMan34]

A question from someone who has not contributed to pnpm in the past and is very excited for this feature

How would I go about contributing to this, if I can?

[gluxon]

Hey @JasonMan34, thanks for the offer to help! I'm focusing on this more extensively over the next few days. I'll give a heads up here if there are any tasks that could use assistance.

• If you'd like to get your feet wet with the pnpm codebase, feel free to take a look at the currently open issues. Fixing a small bug would be a good opportunity to set up the repo, get it compiling, and open a PR.
• I'm certain we'll need help testing the catalogs feature. I'll also give a heads up when we're ready for that.

Would you want to help code review? Extra eyes always helps code quality.

[JasonMan34]

Would you want to help code review? Extra eyes always helps code quality.

Sure absolutely, glad to help any way I can :)

[evelant]

Very excited to see progress on this feature! Maintaining version consistency across a monorepo is a painful chore.

[darkbasic]

Maintaining version consistency across a monorepo is a painful chore.

This is indeed the main reason why I migrated accounts.js to yarn v4. The integrated upgrade-interactive plugin makes it an easy job to ensure that each and every instance of a dependency stays at the same version (the other reason is the fact that it integrates a task runner).

[taozhou-glean]

anywhere to see the progress on this or any UFG issues, excited to see this and hope it can land soon!

[NullVoxPopuli]

for anyone watching this, I happened to make a similar utility before learning about catalogs: https://github.com/NullVoxPopuli/defrag

difference tho is that you don't change anything about your package.json entries.

[zkochan]

There will likely need to be a lockfileVersion increase in the pnpm-lock.yaml file.

If this is the case, it would be best to ship it before v9 is out.