A catalog entry set to a dist-tag, such as `beta` or `latest`, already
says which tag to follow. When `pnpm add` asks for that tag, save the
dependency as `catalog:` and leave the entry as written.
v12 compared the entry with the resolved range only, so prefer mode kept
the dependency direct and strict mode failed with a mismatch. It now
reuses an entry that equals the dist-tag typed in the selector. Only an
explicit tag the registry resolved matches: a versionless re-add does not
match an entry set to the configured default tag, and a tag that
linkWorkspacePackages resolves to a local package keeps its workspace:
specifier.
v11 saved `catalog:` but rewrote the entry to the tag's current version.
The explicit-dist-tag pin added for `pnpm update foo@beta` on an entry set
to a version also fired when the tag came from the catalog entry itself,
because the resolver swaps the entry in as the wanted specifier.
`getCatalogUpdatesOfProject` now skips the update in that case. This also
covers a plain `pnpm add foo`.
Closespnpm/tasks#225.
---------
Co-authored-by: Zoltan Kochan <z@kochan.io>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
