v1.6.1 — the CLI reads installed versions for dist-tag dependencies

Payload Components 1.6.1 is a patch release with one installer fix.

Installer fix

• When package.json declares payload or next without a version (latest, *, workspace:* or catalog:), the CLI now reads the version installed in node_modules for project detection and peer-range checks. It follows pnpm's store symlink to do so. A declared semver range still takes precedence, and if nothing is installed the error explains how to fix it. Projects scaffolded with create-payload-app --version latest declare exactly that, and on 1.6.0 they could not run add, doctor or any other command that detects the project. (#588)

No component source, manifest or runtime dependency changed since 1.6.0, so existing installs have nothing to update.

Validation and upgrading

Before release, the fix passed the bare Payload smoke test and a website smoke shard against Payload latest, including a production build and boot. It also passed the full release gate and packed-artifact checks on the release commit. npx payload-components … picks up 1.6.1 automatically. If you pin the CLI, update it to 1.6.1.

MIT and community-first.

Verified publication

Published from production commit 0756ca82bf46144e7d7ae557bc149cb26cfbbf20. npm latest is 1.6.1, it records that exact git commit, and it carries a provenance attestation. Both production deployments and the push gate passed on that commit.

• Publishing workflow: the full release gate, packed-artifact checks, npm publication and the GitHub Packages mirror all passed.
• Published-package check: on a project whose package.json declares "payload": "latest", with 3.90.2 installed behind a pnpm symlink, npx payload-components@1.6.1 doctor reports [ok] project: payload-website-starter (Payload 3, Next 16, pnpm). Published 1.6.0 on the same project reports Unable to determine the installed major version for "payload".