Zoltan Kochan
b3eee14a96
Part of pnpm/tasks#191. Wrong claims, fixed on the v12 page and on the v11 twin where it had the same text: - audit: `--interactive` implies `--fix=override`; `info` is a valid audit level. - change check validates the pending intents. - deploy copies the publish packlist unless `deployAllFiles` is set. - deprecate: an empty message fails, use `pnpm undeprecate`. - deprecate, dist-tag: only `--otp` supplies the one-time password. - dist-tag add defaults to `latest`, not the `tag` setting. - docs takes exactly one package. - env: there is no `add` subcommand, and `list` queries the Node.js mirror only. - v12 only: clean no longer says it uses Node.js, add no longer presents `-w` as an alias, the deploy package-manager-pin history is no longer contradictory, doctor sample shows store v11. Missing facts: - add: `--save-prefix`, `--save-build`, `--no-save-peer`, `--no-save-types`, `--lockfile-only`, `--force`; where Yarn vs npm and Bun pins go; catalog and configDependencies links. - access status shorthands; approve-builds error codes, the placeholder value and the immediate rebuild; audit exit code, `--optional`, `--production`, and how to make `--ignore` write `audit.ignore`; `--ignore` exits with code 0 and `--ignore-unfixable` fails on an advisory without a GHSA ID. - bugs and docs `--registry`; ci accepts install options; clean script override and modulesDir; config `--location` type and `get` output; create name mapping, `--shell-mode`, `--cpu`, `--os`, `--libc`; dedupe flags; deploy error codes and Dockerfile WORKDIR; dist-tag aliases and web OTP; env `--global` requirement; exec recursive options and PNPM_PACKAGE_NAME; fetch `--ignore-pnpmfile`, lockfile requirement, optional pnpmfile in the Dockerfiles. - usage, examples, and output for bin, cache, cache list, cache delete (with the no-argument warning), cache view, cat-file, cat-index, find-hash, ignored-builds, import, and init (`initPackageManager`, `initType`, ERR_PNPM_PACKAGE_JSON_EXISTS). Stale history on v12 pages: removed "Added in" markers for v10 and v11 and rewrote "Since v11..." passages as current behavior in access, add, approve-builds, audit, bugs, cache-list-registries, cache-path, cache-prune, change, ci, config, create, deploy, deprecate, dist-tag, docs, doctor, help, ignored-builds, and init. Review follow-up: cat-file now says it rejects the hex digest that cat-index prints; the settings index links initPackageManager and initType; `change check` says it plans the release without reporting it (both versions); `pnpm bin` follows a custom modulesDir.
3.8 KiB
id, title
| id | title |
|---|---|
| change | pnpm change |
Added in: v11.13.0
Records a change intent: which packages a change affects, the bump type for each, and a summary that becomes the changelog entry. The intent file is written to .changeset/ in the changesets format.
pnpm change [--bump <type>] [--summary <text>] [<pkg>...]
pnpm change status
pnpm change check
Change intents are consumed later by pnpm version -r. See Release management for the whole workflow.
Usage
Run without arguments to record an intent interactively:
pnpm change
You are asked three questions:
- Which packages does this change affect? Packages changed since the merge base with
main(ormaster) are preselected. - Which packages should have a major bump?, then the same for
minor. Anything left over is bumped aspatch. - Summary of the change, which becomes the changelog entry.
The result is a file such as .changeset/calm-cats-resolve.md:
---
"@example/core": minor
"@example/cli": patch
---
Added a `--watch` flag to the build command.
Commit this file along with your change.
Passing package names together with --bump and --summary records an intent without prompting, which is useful in scripts:
pnpm change --bump patch --summary "Fixed a crash on empty input" @example/core
Subcommands
status
Show the pending change intents and the release plan they produce.
pnpm change status
Pending change intents:
.changeset/calm-cats-resolve.md
Release plan:
@example/core: 1.2.0 → 1.3.0 (minor, via intent)
@example/cli: 0.4.1 → 0.4.2 (patch, via intent+dependencies)
The cause of each bump is one of intent (a change intent named the package), dependencies (a dependent was pulled in by propagation), fixed (a fixed group companion), or epic (an epic re-base).
Private packages ("private": true) are never checked against the registry for a first release, so their pending change intents always show up as bumps, and a workspace of only private packages needs no registry access to plan a release.
check
Added in: v11.26.0
Validate the pending change intents, and check the versions committed in the workspace against the epic bands and fixed group lockstep declared in pnpm-workspace.yaml.
pnpm change check
Unlike pnpm change status, which reports the release the pending intents produce, check plans the release from the pending intents without reporting it, and checks only the versions already in the manifests. An intent that would fail at release time, such as one naming a package outside the workspace, fails the command. Run it on every pull request: a package whose version drifted out of its epic's band, or out of step with its fixed group, fails the command. Every violation is listed, including ones in packages the current release does not touch.
Options
--bump <type>
The bump type for the named packages: none, patch, minor, or major. none records an explicit decline: the change needs no release.
--summary <text>
The summary for the changelog entry. Together with package names, this runs the command non-interactively.
Referencing packages by directory
When two workspace projects publish the same name, a package can be referenced by its workspace-relative directory instead, with a ./ prefix:
---
"./packages/cli": minor
---
This is the one additive extension pnpm makes to the changesets format. pnpm change writes it automatically when a name is ambiguous.