The test failure should have nothing to do with this modification.

I could see some users wanting to leave around a catalog entry in case it'll be used in the future. Should we use a new config for this instead of going off of the existing catalogMode setting name?

I've found reusing configs for new behavior can cause coupling of behaviors that aren't desirable for all users. People setting catalogMode=strict may not realize they're opting into this unrelated check.

IMO, setting catalogMode=strict means that all dependencies are managed in the catalog, so when removing related dependencies, the corresponding dependency information should be removed like pnpm-lock.yaml.

To avoid confusion, we can update the description of catalogMode=strict to clarify this situation.

If we add new configurations, will that be too much?

IMO, setting catalogMode=strict means that all dependencies are managed in the catalog, so when removing related dependencies, the corresponding dependency information should be removed like pnpm-lock.yaml.

While I personally agree, I don't know if this is the case for all users.

There's a new case we should consider: What if users add catalog entries through pnpm config dependencies? We would probably want to omit catalog entries added in this way. Config dependencies are used to share configuration across multiple repos. A given repo may not use every catalog entry in the shared config dependency.

Indeed, there is such a scenario. 🤔

Well, this is the description of catalogMode=strict in our docs:

strict - only allows dependency versions from the catalog. Adding a dependency outside the catalog's version range will cause an error.

It doesn't mention that unused catalog entries are prohibited.

Also, I don't think it should necessarily be limited to catalogMode strict. Why can't we remove unused entries when catalogMode is prefer or manual. I think these are different and new setting would be better.

What's the best approach for handling new configurations? Should I add a configuration that takes effect when removing a catalog dependency, or create a new command to clear unused catalog dependencies?

I think it can work on any install command, not just on remove.

dedupeCatalog doesn't sound right. It isn't deduping anything. Maybe cleanupUnusedCatalogs.

Looks great.

I don't think it is a good idea to do the update of the workspace manifest inside @pnpm/core. Right now as you can see updatedCatalogs is returned from mutateModules and then the update of the workspace manifest happens elsewhere.

Also, I think it is bad already that we currently have 2 functions that write the workspace manifest and you add a third one. Potentially we will be writing this file multiple times. I think we should have only one function with options. So even the addCatalogs function should be removed.

I've made the changes, but I'm not sure I understood you correctly.