yarnpkg
[Feature] Catalog like pnpm
The catalog feature of pnpm is awesome and yarn could have it too.
Describe the user story
"As a monorepo owner, I often want to do install dependencies to a package, but I often face version mismatches between the same dependency being used in any other package in the same monorepo".
Describe the solution you'd like
Installing dependencies in monorepo packages should always use the same version across all packages, pnpm solved this using a catalog feature, which looks very cool. It uses "catalog:" as version in the package json - similar to the "workspace:" for local dependencies.
Describe the drawbacks of your solution
The only drawback I can think of, is labor on yarn side.
Describe alternatives you've considered
A plugin would probably be possible. Given the fact, the workspace plugin was integrated, it probably makes sense to have this in core too..
Reference
- https://x.com/sebastienlorber/status/1813530800731938935
- thx @jantimon for the hint
For the user story given, we already have a tool for that in constraints. And as far as I can tell, pnpm catalogs have no enforcement (yet), unlike constraints.
Catalogs also make adding a dependency to a workspace easier because you can just specify catalog: and don't have to find the version used in other workspaces, but we also have a tool for that in yarn add --interactive.
That said, catalogs does have its advantages. For one, constraints are very powerful, but that also makes it quite unwieldy for a simple use case like this. Also, it does reduce the number of merge conflicts in cataloged dependencies.
I have reservations about implementing catalogs because it largely overlaps with existing features, but I'm not entirely opposed to it.
I'll see what others think about this.
I'd be interested in supporting them - constraints solve some of the same issues, but I think both can coexist. Reusing dependencies across a project is a common need, it makes sense to make that easier without having to write "complex" code rules.
I believe Catalogs are just more convenient than constrains for a lot of devs
For example being able to just run yarn add my-package and have it automatically pull the correct version from the catalog is quite nice
Also updating becomes easier. With catalogs, you only need to change the version in one place, and it propagates across the entire monorepo. This is much simpler than updating the code of a constraint rule and/or multiple package.json files
The same goes for checking which versions of a package are used - one look at the root file is enough to be sure that only a single version is used
yarn could also update the catalog automatically. e.g. once you remove the last usage of a package that's referenced in the catalog it could cleanup the catalog (or show a message)
Extending and changing the catalog is straightforward and can be done without learning an additional api
At the moment I'm focusing on some major refactoring for a future major release, so I didn't get the chance to implement it yet. Help would be appreciated here!
I've been working on implementing this as a plugin (although it is largely incomplete as of now). Curious to see how the official implementation would look like!
Based on the recent discussion about the new Yarn superversion, its implementation is now planned.
https://github.com/yarnpkg/berry/discussions/6608#discussioncomment-11327018
Now there's a Yarn plugin for this: https://github.com/toss/yarn-plugin-catalogs
Bun also recently brought Catalog support which works the same as pnpm Catalog does. There is 1 slight difference with pnpm though, which is the location of that Catalog. Bun decided to add it in the package.json under the workspaces field which would probably be a better option for Yarn since Yarn already have and use the workspaces field.
See https://bun.sh/docs/install/catalogs
