230defacaa
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`. Closes pnpm/tasks#225. --------- Co-authored-by: Zoltan Kochan <z@kochan.io> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>