Add 'rush-pnpm up' support for catalogs

[benkeen]

Addresses: #5578

Right now, when you update packages in a Rush/pnpm repo using rush-pnpm up, it updates the catalog entries in common/temp/pnpm-workspace.yaml, but doesn't update Rush's actual catalog, stored in pnpm-config.json, so the update command doesn't fully work. This has been supported since pnpm@10.12.0. This PR enhances it to update the pnpm-config file too.

I also updated it to fix a small issue where JsonFile.save could throw an error due to an undefined $schema property.

Besides the tests, I've ran manual checks with our own Rush repo to confirm the catalog is getting updated properly.

[benkeen]

Howdy @iclanton, @dmichon-msft - don't suppose either of you have context or time to look at this?

[iclanton]

Shouldn't users be running rush update instead of rush-pnpm update?

[benkeen]

Huh, neat. I never associated those two commands in my mind.

rush update has a very limited, custom interface for Rush itself. What I'm trying to do is offer up all the extra options with pnpm update, for updating subsets of dependencies, like:

pnpm update -r "@babel/*"

That could always be done with rush-pnpm (but not rush update); this PR just lets that command handle catalogs too.

Tell me if I'm being barmy.

[benkeen]

Hey @iclanton - sorry to bug, got some time to look at this, this week? [We'd love this feature for our repo!]

[benkeen]

Hi @octogonz, @dmichon-msft would either of you be free for a review?

[iclanton]

This overall looks fine, but would it be better to just include whatever functionality is missing from rush update?

[benkeen]

This overall looks fine, but would it be better to just include whatever functionality is missing from rush update?

I see what you're saying. I'm on the fence, but I think I'd lean towards keeping them separate. Feels like we'd be overloading rush update.

Couple of thoughts:

• if we did this, we'd need the rush command to work with all supported package managers, and the features and nuances of how each of those update/upgrade commands work (I haven't looked into all the available options for each). We'd only want to enhance the rush update command if it supported them all.
• API-wise, we'd need to separate the "raw" pnpm update command args from the existing rush update command args so there's no conflicts when running rush update, of course. The pnpm cmd allows various arguments we'd need to offer in order to make the command useful, which could be a challenge. They seem low-level enough that I immediately went to updating the rush-pnpm wrapper.

I dunno. I'd say enhance the rush-pnpm command first, then depending on how it goes and what sort of demand is shown, consider elevating the functionality to the full rush update later.

[benkeen]

Updated, thanks @iclanton.

[iclanton]

Left some comments about test cleanup and async-ifying things.

Otherwise I think the gist of this is fine.

[benkeen]

Updated, thanks @iclanton.