Feature Request: angular-style catalog

[bgotink]

The catalog protocol currently requires listing every package explicitly, and each package is resolved separately.
Certain projects produce multiple packages with aligned version numbers, which are designed to be used with an identical version. An example is Angular, where using @angular/common version 21.2.3 requires that you also use @angular/core at exactly version 21.2.3.

In our org we've created a yarn berry plugin that implements something alike to the catalog protocol but with two changes:

• Wildcards in selecting the packages (actually regex, but wildcard is good enough)
• An option for packages to "inherit" the version number from another package

So the feature request is for two things that together would mean we could throw out our plugin:

• Extend the catalog configuration to support patterns. If a package name is present in multiple patterns, the first match would be used
• Introduce a new protocol, let's call it copyResolutionFrom for the sake of this feature request. This protocol accepts a descriptor and resolves to the exact same version that that descriptor resolves to.

The angular catalog to replace our custom plugin could look like this:

catalogs:
  angular:
    "@angular/cdk": "npm:^19.0.0-rc"
    "@angular/material": "npm:^19.0.0-rc"
    "@angular/google-maps": "npm:^19.0.0-rc"
    "@angular/cli": "npm:^19.0.0-rc"
    "@angular/build": "copyResolutionFrom:@angular/cli@catalog:angular"
    "@angular-devkit/architect": "npm:>= 0.1900.0-rc < 0.2000.0"
    "@angular-devkit/*": "copyResolutionFrom:@angular/cli@catalog:angular"
    "@schematics/angular": "copyResolutionFrom:@angular/cli@catalog:angular"
    "@angular/core": "npm:^19.0.0-rc"
    "@angular/*": "copyResolutionFrom:@angular/core@catalog:angular"
    "zone.js": "npm:~0.15.0"

[arcanis]

It feels to me this enters constraints territory - constraints can't currently impact catalog dependencies but it'd make sense if they could.

[bgotink]

It was my understanding that constraints are limited to what's in the package.json, while this hypothetical copyResolutionFrom protocol would not just ensure that @angular/forms and @angular/core have the same range in the package manifest but also that they'd resolve to the same exact version.
Using just a catalog with the same range for every package or using constraints would mean installing @angular/core today and adding in @angular/forms next week could lead to different versions being used for these packages in the end.

Assuming all of these packages have their peer dependencies set up correctly (@angular/forms has a peer dep on @angular/core using a fixed version number) this would cause warnings, so it's not like the developer doesn't know something's off.
Fixing it is extremely painful though: updating @angular/forms would require updating @angular/core which would in turn require updating @angular/platform-browser, @angular/common, … since they all have a strict peer dep on @angular/core.
In the end, after all these manual interventions, the user would not just have installed @angular/forms but also updated all angular packages, which they didn't necessarily want to do.