Add --enable-pnpm-catalog flag to opt into pnpm workspace catalog detection - #1714

🦋 Changeset detected

Latest commit: 3f7aac5

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Codecov Report

❌ Patch coverage is 83.33333% with 9 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (main@ca0be26). Learn more about missing BASE report.
⚠️ Report is 61 commits behind head on main.

@@           Coverage Diff           @@
##             main    #1714   +/-   ##
=======================================
  Coverage        ?   80.87%           
=======================================
  Files           ?       54           
  Lines           ?     2311           
  Branches        ?      703           
=======================================
  Hits            ?     1869           
  Misses          ?      437           
  Partials        ?        5           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Found out about pnpm catalogs yesterday (awesome feature!) and this is the only blocker stopping us from adopting them. Anything we can do to help with merging this PR?

I'm happy to work on any change that would be necessary to get this through the finish line.

Is catalog: useful mainly for external packages outside of the monorepo? If yes, then it seems we should make the auto-bumps based on its changes an option. If you think about catalog: as being just a sugar over inlined versions from the catalog then Changesets would, traditionally, not bump your monorepo packages based on changes to external dependencies. There were requests to make that work though so perhaps this would be a good occasion to implement this as a flag if you have already implemented the core sinceRef~ logic for the catalog anyway.

Thanks for the reply!

Changesets would, traditionally, not bump your monorepo packages based on changes to external dependencies

This doesn't seem right. If my package depends on React 17 and I bump it to 18, it requires a version bump of my package.

But happy to have a flag if that's what it takes. I can try to take a stab at it next week.

Changesets will generate a change for any files in a normal (flat) repository right? In the monorepo catalog case, there could be no file changes under each of the packages, but the workspace file (and associated catalog entries) IS modified, which would mean a change, which is what @cyril-sf has implemented I think?

@chriswiggins correct!

@Andarist I've added a --enable-pnpm-catalog option.

I'm not sure how to test end to end without the code being part of a release. I usually just run npx changeset.

Let me know if it's good or if you have feedback!

I would love to see this merged, I worked on an improvement to have a single catalog for all the packages/apps inside our monorepo.

However, since we also rely on renovate PRs to upgrade our dependencies, they all fail on the CI because the changeset generated no changes.

I just wanted to respond to this as it bit us over at SvelteKit today:

If you think about catalog: as being just a sugar over inlined versions from the catalog then Changesets would, traditionally, not bump your monorepo packages based on changes to external dependencies. There were requests to make that work though so perhaps this would be a good occasion to implement this as a flag if you have already implemented the core sinceRef~ logic for the catalog anyway.

This isn't really correct, at least not as I'm reading it. When you publish a package with catalog:x versions, the catalog:x in that package's package.json is replaced with the version from the workspace catalog. So, in effect, updating the version in the workspace catalog is the same as you manually going into each package.json that references that package using catalog:x and updating the version there. If you were to do that manually, you'd have to change the package.json in each package, which would show up as a change to changesets. Ergo, changing the catalog file should show up as a change for each package that references the updated dependency.

Hoping this can get merged at some point; we'd love to be able to use catalogs as our monorepo has quite a few packages and we're basically stuck only using it for dev dependencies.

@Andarist (or an admin on this repo), any chance to get some feedback one way or the other?

Would love to see catalog support getting added, it just makes managing deps so much easier, especially together with changesets. Is there any movement on this?

Perhaps a little more generic, to also support Yarn's catalogs?