@wpelevator/wp-release 0.11.0 → 0.13.0

package/README.md

@@ -34,6 +34,8 @@ npx wp-release --help
 | `wp-release version-check [<source-dir>] [options]` | Check that the `Version` header, readme `Stable tag`, PHP constants and git tag agree. |
 | `wp-release deploy-svn [<source-dir>] [options]` | Deploy a plugin to the WordPress.org plugin SVN repository. |
 | `wp-release deploy-git [<source-dir>] --git-url <url> [options]` | Deploy the files of a plugin, theme or package to a Git repository as a release commit. |
+| `wp-release deploy-git --release-ref <ref> [--package <name>] [--list]` | Deploy the configured packages of a release tag or branch to their Git targets. |
+| `wp-release deploy-svn --release-ref <ref> [--package <name>] [--list]` | Deploy the configured plugin of a release tag to WordPress.org. |
 | `wp-release changeset-add [options]` | Record the release impact of a pull request. |
 | `wp-release changeset-status [options]` | List pending releases and check changed packages for changesets. |
 | `wp-release changeset-version [options]` | Apply version bumps and changelog entries. |
@@ -68,6 +70,7 @@ Each command also adds a section to the [job summary](https://docs.github.com/en
 | `sign` | Signature files and the public key. |
 | `verify` | That all files match, or the counts and a table of the changed, missing and extra files. |
 | `version-check` | The matching version, or a table of the mismatches with their files and lines. |
+| `changeset-status` | Each changed package with whether it has a changeset. |
 | `changeset-version` | A table of the package releases with their version changes and bumps. |
 | `changeset-tag` | Each tag with its previous tag and status, and its release notes in a collapsed section. |
 
@@ -77,7 +80,7 @@ Use global `--config <path>` to select a config; relative paths resolve from the
 
 ### Changesets support (experimental)
 
-Changesets support is experimental. It reads Changesets-style Markdown and loads JavaScript configs with descriptors for npm and Composer manifests, plugin and theme headers, readme Stable tags, PHP constants, and Git tags. Use ESM (`export default`) or CommonJS (`module.exports`); TypeScript configs are not supported. Frontmatter accepts `package-name: patch|minor|major` entries; advanced YAML and prerelease mode are unsupported.
+Changesets support is experimental. It reads Changesets-style Markdown and loads JavaScript configs with descriptors for npm and Composer manifests, plugin and theme headers, readme Stable tags, PHP constants, and Git tags. Use ESM (`export default`) or CommonJS (`module.exports`); TypeScript configs are not supported. Frontmatter accepts `package-name: patch|minor|major` entries; advanced YAML and the Changesets pre mode are unsupported (see [pre-releases](#pre-releases) for the alternative).
 
 Typical release flow, from a feature pull request to the publish workflows triggered by release tags:
 
@@ -124,22 +127,25 @@ export default defineConfig( {
 
 `version.from` selects the current version; `version.to` lists release targets. Package globs support `*`, `?` and `**`; `{path}` in tag templates is relative to `root`. Templates also accept `{type}`, `{name}` and `{slug}`, while `tagType` customizes the type label. Use `phpConstantVersion( { file, constant } )` to sync a PHP constant.
 
-The default strategy requires stable `x.y.z` versions. Configure `nextVersion( { package, bump, currentVersion, changesets } )` for other formats; changeset bumps remain `patch`, `minor` or `major`, and prerelease syntax is unsupported.
+The default strategy bumps stable `x.y.z` versions with SemVer rules, and the `x.y` and `x.y.z.w` versions common in WordPress plugins the same way: the bumped part is raised, the parts after it reset to `0`, and the version keeps its number of parts. A minor bump of `2.1` is `2.2` and a major bump is `3.0`, while a patch bump adds the third part, `2.1.1`. A patch bump of `1.2.3.4` is `1.2.4.0`, so raising only the fourth part needs a custom strategy. Configure `nextVersion( { package, bump, currentVersion, changesets } )` for other formats; changeset bumps remain `patch`, `minor` or `major`. Pre-releases are added to the next version with `--prerelease`, described below.
 
 Without `--since`, `changeset-status` compares against `origin/<baseBranch>`; fetch that ref or pass `--since` when using a fork or different upstream. `loadChangesetConfig()` discovers a conventional config at the repository root, unless `--config <path>` selects one explicitly.
 
-Add release notes in a feature PR with `npx wp-release changeset-add --package @vendor/plugin --bump patch --summary "Fix the checkout validation."`. Repeat package and bump flags for multiple packages, or use `--empty` when no release is needed. In CI, `changeset-status --since origin/main` requires a changeset added by the PR; changesets already on the base do not count, while an empty PR changeset records an explicit no-release decision. Missing-change annotations identify an affected file.
+Add release notes in a feature PR with `npx wp-release changeset-add`. In a terminal, it lists the packages, marks the ones that changed since `origin/<baseBranch>` (or `--since <ref>`) without a changeset, and asks for the packages to release, a `patch`, `minor` or `major` bump for each, and the release note. Choose packages by number, identifier or path, or press Enter to release the changed ones; `none` adds an empty changeset. Changed files include uncommitted and untracked ones, since changesets are usually added before committing.
+
+Without a terminal, or for scripts, pass the changeset as options: `npx wp-release changeset-add --package @vendor/plugin --bump patch --summary "Fix the checkout validation."`. Repeat package and bump flags for multiple packages, or use `--empty` when no release is needed. A package can also be named by its path under `root`, like `plugins/alpha`, and the changeset records its identifier; `changeset-version --package` and `changeset-tag --package` accept paths too. A single `--bump` without `--package` releases every changed package without a changeset, like `changeset-add --bump patch --summary "…"` to fix a failing `changeset-status` check. `--json` and `--github-output` never ask.
+
+In CI, `changeset-status --since origin/main` requires a changeset added by the PR; changesets already on the base do not count, while an empty PR changeset records an explicit no-release decision. Missing-change annotations identify an affected file.
 
 On the release branch, preview with `changeset-version --dry-run`, then run `changeset-version` to update version targets and changelogs. By default, new Markdown entries go before the first version heading; `changelogInsertAfter` sets a literal insertion marker for `CHANGELOG.md` and, with `readmeChangelog`, the plugin readme. Put the marker in both files; a missing marker is an error. Without a marker, plugin readmes use the `== Changelog ==` heading. Failed updates are rolled back for safe retries.
 
-Configure `changelogEntry( { package, changeset, commit } )` to format the changelog entry of each changeset, where `commit` is the `{ hash, shortHash, subject }` of the commit that added the changeset file, if it's committed. The formatted entries go into `CHANGELOG.md`, the `changelog` of each release in the `changeset-version` result, and so the release notes; plugin readmes keep the plain summaries. `getGitHubPullRequest( { cwd, commit } )` finds the `{ number, url, author }` of the pull request that merged a commit with the authenticated `gh` CLI, for example to credit it:
+Configure `changelogEntry( { package, changeset, commit } )` to format the changelog entry of each changeset, where `commit` is the `{ hash, shortHash, subject }` of the commit that added the changeset file, if it's committed. The formatted entries go into `CHANGELOG.md`, the `changelog` of each release in the `changeset-version` result, and so the release notes; plugin readmes keep the plain summaries. Without the callback, entries are the plain summaries. For example, to link each entry to its commit:
 
 ```js
-changelogEntry: async ( { changeset, commit } ) => {
-	const pullRequest = commit && ( await getGitHubPullRequest( { cwd: import.meta.dirname, commit: commit.hash } ) );
-
-	return pullRequest ? `${ changeset.summary } (#${ pullRequest.number } by @${ pullRequest.author })` : changeset.summary;
-},
+changelogEntry: ( { changeset, commit } ) =>
+	commit
+		? `${ changeset.summary } ([\`${ commit.shortHash }\`](https://github.com/me/repo/commit/${ commit.hash }))`
+		: changeset.summary,
 ```
 
 Configure `dependents` to re-release packages that bundle a package when it releases. The dependents come from what the packages declare: a package is a dependent of a source when the spec that it declares in its npm `dependencies` or `optionalDependencies` (or the sections that the policy adds) resolves the current version of the source or points at the workspace, and it re-releases when the next version of the source falls outside the declared range, or always with `when: 'always'`. A pin to an older version selects a registry release instead and `changeset-status` warns about the drift until the pin resolves the package again. Versioning a dependent rewrites its declared specs of the source to the released version, keeping their range prefixes, so an exact pin matches the released workspace again and the built bundle matches the changelog. Wildcards and unpinned ranges accept the release without one, like the `devDependencies` of a package. The derived dependents appear in `changeset-status`, `changeset-version` and `changeset-tag` like any other release, and a dependent that releases for its own reasons keeps its own bump and appends the bundle note:
@@ -153,6 +159,8 @@ dependents: {
 
 Excluded packages still release with their own changesets and stay out of the automatic re-releases.
 
+When the changesets of a pull request release a source, `changeset-status` requires no changeset for a dependent whose only change is the spec of that source in its `package.json`, since versioning rewrites the spec and the bundle note announces it. Any other change to the dependent, like another manifest field or dependency, documentation or code, needs its own changeset.
+
 The bundle changelog entry defaults to `Bundle <source> <version>.` and is formatted with `dependents.changelog( { package, source } )`:
 
 ```js
@@ -204,10 +212,37 @@ To release a single package, for example from a manual workflow, pass `--package
     prerelease: ${{ fromJSON( steps.tag.outputs.result ).tags[0].prerelease }}
 ```
 
-The release notes are the version's `CHANGELOG.md` section, or without one the commits that changed the package since its previous tag, the highest version below the released one. Configure `releaseNotes( { package, version, tag, previousTag, changelog, commits, notes } )` to format them, for example to add links; `notes` is the default text and `commits` lists `{ hash, shortHash, subject }`, newest first. `changeset-tag --package <name> --dry-run` prints them without creating the tag.
+The release notes are the version's `CHANGELOG.md` section, or without one the commits that changed the package since its previous tag, the highest version below the released one, skipping pre-releases for a stable version. Configure `releaseNotes( { package, version, tag, previousTag, changelog, commits, notes } )` to format them, for example to add links; `notes` is the default text and `commits` lists `{ hash, shortHash, subject }`, newest first. `changeset-tag --package <name> --dry-run` prints them without creating the tag.
 
 For local development, run the TypeScript source with `npm run wp-release -- <command>` (for example, `npm run wp-release -- changeset-status --since origin/main`). GitHub workflows use the same CLI for versioning and tagging. `SUBTREE_DEPLOY_TOKEN` lets them update the release PR and push tags, and the `Tag Release` workflow passes it to `softprops/action-gh-release` to create the GitHub Releases.
 
+#### Pre-releases
+
+`changeset-version --prerelease <id>` (the `prerelease` option of `versionChangesets()`) releases pre-releases of the next versions, like `1.3.0-rc.1` for a minor bump of `1.2.0`. The identifier, like `alpha`, `beta` or `rc`, can have a number, like `rc.2`, which is used as is and fails when the version is already tagged. Without a number, the number is one above the highest existing tag of that identifier and next stable version, read with the `tagFormat` of the package, so the first one is `rc.1`, and the numbering starts again at `.1` when later changesets raise the next version. The dependents of a source become pre-releases too, so that they bundle its pre-release, unless they're left out with `--no-dependents`.
+
+A pre-release writes every version target except the readme `Stable tag`, which keeps the last stable version since WordPress.org offers it to every site, and `changeset-tag` skips the `Stable tag` when it verifies a pre-release. The changelog gets a section for the pre-release, like `## 1.3.0-rc.1 (2026-10-12)`, so that `changeset-tag` finds its release notes, and the changesets are consumed like in any release.
+
+Since a pre-release consumes the changesets that the stable release needs, run it on a branch that isn't merged, and tag that branch commit:
+
+```sh
+git switch --force-create prerelease/plugins/alpha
+npx wp-release changeset-version --package plugins/alpha --prerelease rc
+git add --all
+git commit --message "Prerelease plugins/alpha"
+npx wp-release changeset-tag --package plugins/alpha --version 1.3.0-rc.1 --push
+```
+
+The base branch keeps its stable versions and pending changesets, so the stable release later versions them as usual, in one changelog section. The tag keeps the pre-release commit reachable after the branch is reset or deleted. The release notes of a stable release compare with the previous stable release, skipping the pre-releases before it, and the `git-tag` version source ignores pre-release tags, so packages versioned by git tags keep building on their last stable version.
+
+#### Snapshots
+
+`changeset-version --snapshot <id>` (the `snapshot` option of `versionChangesets()`) releases snapshots of the next versions for test builds, like `1.3.0-pr-251.20261012183005` for a pull request: the next version with the identifier, like `pr-251` or `pr-251.0abc123` with a commit hash, and the UTC time, so that every snapshot is unique and they sort by time. Snapshots aren't numbered from tags and can't be combined with `--prerelease`. Like a pre-release, a snapshot writes every version target except the readme `Stable tag`. Build and publish the versioned files without committing them, for example under an npm dist-tag like `pr-251`, since a snapshot consumes the changesets:
+
+```sh
+npx wp-release changeset-version --package @vendor/library --snapshot pr-251
+npm publish --workspace packages/library --tag pr-251
+```
+
 ### Naming convention
 
 `@wpelevator/wp-release` is the suite of release tools and `wp-release` is its CLI. "Release" is the whole workflow; each command is one operation in it. Commands are flat: a single word or dashed words like `version-check` and `deploy-svn`, without command groups or aliases. Each GitHub Action is named `wp-release-` followed by the command name, so the CLI command and the `uses:` name always match:
@@ -457,7 +492,54 @@ How a deploy works:
 
 To release a tag again, for example after a release with the wrong files, delete the tag in the repository (`git push <url> :refs/tags/<tag>`) and run the deploy again. There's no flag for replacing a tag, since installs, Composer and GitHub Actions pins trust that a published tag doesn't change.
 
-`--dry-run` runs everything except the push. `--message` sets the commit message, which defaults to `Release <tag or branch> from <source commit>`. Credentials come from git, like a token in the URL or an SSH key, and credentials in URLs are never printed. The commit needs a git identity (`user.name` and `user.email`).
+`--dry-run` runs everything except the push. `--message` sets the commit message, which defaults to `Release <tag or branch> from <source commit>`. Credentials come from git, like a credential helper or an SSH key, and credentials in URLs are never printed. For an HTTPS repository on `github.com`, or on the host of `GITHUB_SERVER_URL` like GitHub Enterprise Server, the `GITHUB_TOKEN` environment variable is sent as an authorization header, like `actions/checkout` does, so the token stays out of the URL, the git arguments and the repository config, and it replaces the header that `actions/checkout` persists. Pass `token` to `resolveGitDeployOptions()` for another HTTPS host. The commit needs a git identity (`user.name` and `user.email`).
+
+### Deploy configured packages
+
+`deploy-git --release-ref <ref>` and `deploy-svn --release-ref <ref>` deploy the packages of a monorepo, or of a single-package repository, to the targets in the `deploy` config of their package groups, like the release repository of each package or its WordPress.org plugin. The ref decides what's deployed: a release tag of a package, like `refs/tags/plugins/alpha/1.2.0` read with the `tagFormat`, deploys that package and version, and a branch, like `refs/heads/main`, deploys every package with a target for that branch. A name without `refs/` is a release tag when it matches the tag format of a package, otherwise a branch, and in GitHub Actions `$GITHUB_REF` is the pushed ref.
+
+```js
+packages: [
+	{
+		glob: 'plugins/*',
+		version: { from: wordpressPluginVersion(), to: [ wordpressPluginVersion(), wordpressStableTag() ] },
+		// Files that the deploys ship, instead of each package's .distignore.
+		files: { distignore: false, exclude: [ '.*', 'node_modules/', '/tests/' ] },
+		deploy: {
+			git: [
+				// The release repository of each plugin, with its history.
+				{ repository: 'https://github.com/me/{slug}.git', message: 'Release {path} {ref} from {revision}' },
+				// A mirror that only gets release tags, named v1.2.0.
+				{ repository: ( { package: pkg } ) => `https://gitlab.com/me/${ pkg.path }.git`, branches: false, tag: 'v{version}' },
+			],
+			svn: { slug: 'me-{slug}', assetsDir: '.wordpress-org' },
+		},
+	},
+	// A package that isn't versioned, like a Docker image, only deploys branches.
+	{ glob: 'docker/php-fpm', deploy: { git: { repository: 'https://github.com/me/php-fpm.git' } } },
+],
+```
+
+| Mode | Command | Use |
+|---|---|---|
+| All | `deploy-git --release-ref <ref>` | Deploy every package of the ref to each of its targets, one at a time, in one log group for each package. A failed deploy doesn't stop the others, and the command exits with `1` at the end. |
+| One package | `deploy-git --release-ref <ref> --package <name>` | Deploy only that package (repeatable), by identifier or path, for example to retry a failed one or in a CI job for each package with its own credentials. |
+| Plan | `deploy-git --release-ref <ref> --list` | List the deploys without running them, with each package, its version or branch and the targets with the tag or branch they get. With `--json` or `--github-output` the result is `{ packages: [ … ] }`, for a CI matrix with `include: ${{ fromJSON( steps.plan.outputs.result ).packages }}`. |
+| Single directory | `deploy-git <dir> --git-url <url> [options]` | Deploy one directory without a config, as described above. |
+
+`deploy-svn` has the same modes. `--release-ref` can't be combined with the options of a single target, like `--git-url`, `--tag` or `--svn-tag`, which come from the config.
+
+- **Git targets** take a `repository` and release both branches and tags by default. `branches` limits the branches, like `[ 'main' ]`, or turns them off with `false`, and `tag` is the tag template in the repository, `{version}` by default, or `false` to not release tags. A release tag is created on top of the default branch of the repository, and a branch is released to the same branch. `history: false` uses the source commit instead of the package history from `git subtree split`, and `message` sets the release commit message, `Release {ref} from {revision}` by default.
+- **SVN targets** only deploy release tags: a stable release syncs `trunk/`, creates its tag and syncs the `assetsDir`, and a pre-release only creates its tag. `slug` defaults to `{slug}`, `url` to the WordPress.org plugin repository, and `message` sets the commit message. Credentials come from `SVN_USERNAME` and `SVN_PASSWORD`, or `--svn-username`.
+- **Several targets**: `git` and `svn` each take one target or a list, like a release repository and a mirror on another host. Each target is a separate deploy.
+- **Credentials**: a GitHub repository URL needs no token in it, since `GITHUB_TOKEN` is sent as an authorization header (see above). A callback can still add credentials for other hosts.
+- **Templates and callbacks**: `repository`, `slug` and `message` are templates with `{name}`, `{slug}`, `{path}` and `{type}`, like the `tagFormat`, and `{version}`, `{branch}`, `{ref}` (the tag or branch that the deploy writes in the target) and `{revision}` (the source commit), or callbacks that receive `{ package, version, branch, ref, revision }`, where `package` has the `name`, `directory`, `path` and `type`. A callback can choose another host for some packages, read the environment, or return nothing to skip the target for that package or ref; an empty `message` uses the default one. Credentials in URLs are never printed or listed.
+- **Packages without a version**: a package entry without `version`, like a single directory with a `glob` of its path, isn't released with changesets, so changes to it don't need one, and it only deploys branches, since it has no release tags.
+- **Files**: `files.exclude` adds gitignore-style patterns relative to the package directory, and `files.distignore` sets the ignore file relative to it or turns it off with `false`. A `files` at the root of the config applies to every package group, for the rules that all packages share, and the `files` of a group add their patterns after it and can replace its ignore file. Without `files`, each package's `.distignore` applies, like for `zip`; there's no repository-wide `.distignore`, since each one is relative to its package. `getDeployPackages()` lists the packages with their file selection, for example to build a ZIP with the same files.
+
+A deploy releases the files of the working tree, so build the packages first. One job that builds once and runs `deploy-git --release-ref "$GITHUB_REF"` is the simplest setup, also for a branch that releases every package. A matrix with a job for each package from `--list` would build every package in every job, so build once and pass the built tree to the jobs as an artifact if you need one, for example for separate credentials.
+
+Other monorepo tools split the same way with less of the release in the config: [splitsh-lite](https://github.com/splitsh/lite), [Symplify MonorepoBuilder](https://github.com/symplify/monorepo-builder) and [`danharrin/monorepo-split-github-action`](https://github.com/danharrin/monorepo-split-github-action) push the source history of each package directory, with the packages and repositories listed in the workflow or a matrix, while `deploy-git` releases the built files on top of that history, so `vendor/` and `build/` reach Composer and WordPress installs. Like the publishers of [GoReleaser](https://goreleaser.com/), targets are lists with templates, and pre-releases skip the targets where they would replace the stable version.
 
 ### Exit codes
 
@@ -642,7 +724,7 @@ The changeset release modules, from the entry point down:
 |---|---|
 | `changeset-release.ts` | `ChangesetRelease`, which plans releases and runs `add()`, `getStatus()`, `version()` and `tag()`, and the function form of each operation. |
 | `changeset-config.ts` | Loading and validating `wp-release.config.js`, and the version source and target helpers. |
-| `changeset-packages.ts` | Discovering the packages of the configured globs and finding the changed ones. |
+| `changeset-packages.ts` | Discovering the packages of the configured globs, with or without a version, and finding the changed ones. |
 | `changeset-files.ts` | Reading, writing and consuming changeset files. |
 | `changeset-dependents.ts` | The dependents policy: which packages re-release with their sources, and rewriting their dependency specs. |
 | `changesets.ts` | Parsing and formatting changesets, and the release types. |
@@ -650,8 +732,8 @@ The changeset release modules, from the entry point down:
 | `changelog.ts` | Changelog entries, and the `CHANGELOG.md` and readme changelog sections. |
 | `release-tags.ts` | Choosing the version and previous tag of a release, and building its release notes. |
 | `tag-format.ts` | Formatting tag names from the tag format. |
+| `package-deploy.ts` | Resolving the configured deploys of a ref: the released packages, their targets and file selections, for `deploy-git` and `deploy-svn`. |
 | `release-repository.ts` | `ReleaseRepository`, the git commands of a release: tags, commits and changed files. |
-| `github.ts` | Finding the pull request of a commit with the GitHub CLI, for changelog formatters. |
 | `file-journal.ts` | `FileJournal`, which restores every file a failed `changeset-version` run changed. |
 | `versions.ts` | Version checks and SemVer precedence. |
 

package/dist/changeset-config.d.ts

@@ -66,8 +66,83 @@ export interface ChangesetPackageGroup {
     tagType?: string;
     /** Manifest field used as the changeset name; defaults to `path`. */
     idFrom?: PackageIdSource;
-    /** Version source and files to update for every discovered package. */
-    version: PackageVersionConfig;
+    /**
+     * Version source and files to update for every discovered package. Without
+     * it, the packages aren't released with changesets and only deploy branches.
+     */
+    version?: PackageVersionConfig;
+    /** Files that the deploys of the packages ship. */
+    files?: PackageFilesConfig;
+    /** Where `deploy-git` and `deploy-svn --release-ref` deploy the packages. */
+    deploy?: PackageDeployConfig;
+}
+/** Files that the deploys of a package ship. */
+export interface PackageFilesConfig {
+    /** Ignore file relative to the package directory, or false to not read one; defaults to .distignore when present. */
+    distignore?: string | false;
+    /** Extra gitignore-style patterns relative to the package directory. */
+    exclude?: string[];
+}
+/** A package and the release that a deploy target is resolved for. */
+export interface DeployTargetInput {
+    /** Deployed package. */
+    package: DeployPackage;
+    /** Released version, for a release tag. */
+    version?: string;
+    /** Deployed branch, for a branch. */
+    branch?: string;
+    /** Tag or branch that the deploy writes in the target: the tag of a release, or the branch. */
+    ref: string;
+    /** Source commit of the deploy. */
+    revision: string;
+}
+/** A configured package that a deploy target receives. */
+export interface DeployPackage {
+    /** Package identifier. */
+    name: string;
+    /** Absolute package directory. */
+    directory: string;
+    /** Package path relative to the configured root. */
+    path: string;
+    type: ChangesetPackage['type'];
+}
+/**
+ * A deploy setting: a template with {name}, {slug}, {path}, {type},
+ * {version}, {branch}, {ref} and {revision}, or a callback that receives the
+ * package and its release. An empty repository or slug skips the target, and
+ * an empty message uses the default one.
+ */
+export type DeployTemplate = string | ((input: DeployTargetInput) => string | undefined | Promise<string | undefined>);
+/** A Git repository that `deploy-git` releases a package to. */
+export interface GitDeployTarget {
+    /** Repository URL, like `https://github.com/me/{slug}.git`. */
+    repository: DeployTemplate;
+    /** Branches released to the same branch of the repository: all with true (the default), none with false, or the listed ones. */
+    branches?: boolean | string[];
+    /** Tag of a release in the repository, with {version} and the package placeholders, defaults to `{version}`; false to not release tags. */
+    tag?: string | false;
+    /** Whether the package history from git subtree split is the source history of the releases; defaults to true. */
+    history?: boolean;
+    /** Release commit message, like `Release {path} {ref} from {revision}`; defaults to `Release {ref} from {revision}`. */
+    message?: DeployTemplate;
+}
+/** A WordPress.org plugin that `deploy-svn` releases a package to. */
+export interface SvnDeployTarget {
+    /** Plugin slug, defaults to `{slug}`. */
+    slug?: DeployTemplate;
+    /** SVN repository URL with {slug}, defaults to WordPress.org. */
+    url?: string;
+    /** Directory with banners, icons and screenshots relative to the package, synced to assets/ with stable releases. */
+    assetsDir?: string;
+    /** Readme file relative to the package, defaults to readme.txt. */
+    readme?: string;
+    /** SVN commit message, like `Release {version}`. */
+    message?: DeployTemplate;
+}
+/** Deploy targets of a package group, each one target or a list of them. */
+export interface PackageDeployConfig {
+    git?: GitDeployTarget | GitDeployTarget[];
+    svn?: SvnDeployTarget | SvnDeployTarget[];
 }
 /** Inputs supplied to a dependents changelog formatter. */
 export interface DependentsChangelogInput {
@@ -166,6 +241,8 @@ export interface ChangesetConfig {
     changelogEntry?: (input: ChangelogEntryInput) => string | Promise<string>;
     /** Groups of packages re-released whenever one of their source packages releases. */
     dependents?: DependentsConfig;
+    /** Files that the deploys of every package group ship; the `files` of a group add their patterns and can replace the ignore file. */
+    files?: PackageFilesConfig;
 }
 /** Inputs supplied to a custom next-version strategy. */
 export interface NextVersionInput {
@@ -293,3 +370,10 @@ export declare function loadChangesetConfig(input?: LoadChangesetConfigInput): P
     config: ChangesetConfig;
     file: string;
 } | undefined>;
+/**
+ * Normalize a deploy target setting to a list of targets.
+ *
+ * @param value One target, a list of them or undefined.
+ * @return Targets.
+ */
+export declare function toTargetList<Target>(value: Target | Target[] | undefined): Target[];

package/dist/changeset-config.js

@@ -250,13 +250,15 @@ function validateChangesetConfig(config, configFile) {
         'function' !== typeof candidate.releaseNotes) {
         throw new ValidationError(`wp-release config ${configFile}.releaseNotes must be a function.`);
     }
+    validateFilesConfig(candidate.files, `${configFile}.files`);
     candidate.packages.forEach((group, index) => {
         if ('object' !== typeof group ||
             null === group ||
-            'object' !== typeof group.version ||
-            null === group.version ||
-            'object' !== typeof group.version.from ||
-            !Array.isArray(group.version.to)) {
+            (undefined !== group.version &&
+                ('object' !== typeof group.version ||
+                    null === group.version ||
+                    'object' !== typeof group.version.from ||
+                    !Array.isArray(group.version.to)))) {
             throw new ValidationError(`wp-release config ${configFile} has an invalid packages[${index}] entry.`);
         }
         if (undefined !== group.idFrom &&
@@ -275,9 +277,102 @@ function validateChangesetConfig(config, configFile) {
                 group.exclude.some((item) => 'string' !== typeof item))) {
             throw new ValidationError(`wp-release config ${configFile} packages[${index}].exclude must be an array of strings.`);
         }
-        validateVersionDescriptor(group.version.from, `${configFile}.packages[${index}].version.from`, false);
-        group.version.to.forEach((target, targetIndex) => validateVersionDescriptor(target, `${configFile}.packages[${index}].version.to[${targetIndex}]`, true));
+        if (group.version) {
+            validateVersionDescriptor(group.version.from, `${configFile}.packages[${index}].version.from`, false);
+            group.version.to.forEach((target, targetIndex) => validateVersionDescriptor(target, `${configFile}.packages[${index}].version.to[${targetIndex}]`, true));
+        }
+        validateFilesConfig(group.files, `${configFile}.packages[${index}].files`);
+        validateDeployConfig(group.deploy, `${configFile}.packages[${index}].deploy`);
+    });
+}
+function isObject(value) {
+    return ('object' === typeof value && null !== value && !Array.isArray(value));
+}
+function validateFilesConfig(files, location) {
+    if (undefined !== files && !isObject(files)) {
+        throw new ValidationError(`wp-release config ${location} must be an object.`);
+    }
+    const { distignore, exclude } = (files ?? {});
+    if (undefined !== distignore &&
+        false !== distignore &&
+        ('string' !== typeof distignore || !distignore)) {
+        throw new ValidationError(`wp-release config ${location}.distignore must be a file path or false.`);
+    }
+    if (undefined !== exclude &&
+        (!Array.isArray(exclude) ||
+            exclude.some((item) => 'string' !== typeof item))) {
+        throw new ValidationError(`wp-release config ${location}.exclude must be an array of strings.`);
+    }
+}
+function validateDeployConfig(deploy, location) {
+    if (undefined !== deploy && !isObject(deploy)) {
+        throw new ValidationError(`wp-release config ${location} must be an object.`);
+    }
+    const targets = (deploy ?? {});
+    Object.keys(targets).forEach((key) => {
+        if (!['git', 'svn'].includes(key)) {
+            throw new ValidationError(`wp-release config ${location}.${key} is not a deploy target; use git or svn.`);
+        }
     });
+    toTargetList(targets.git).forEach((target, index) => validateGitTarget(target, `${location}.git[${index}]`));
+    toTargetList(targets.svn).forEach((target, index) => validateSvnTarget(target, `${location}.svn[${index}]`));
+}
+/**
+ * Normalize a deploy target setting to a list of targets.
+ *
+ * @param value One target, a list of them or undefined.
+ * @return Targets.
+ */
+export function toTargetList(value) {
+    if (undefined === value) {
+        return [];
+    }
+    return Array.isArray(value) ? value : [value];
+}
+function isTemplate(value) {
+    return (('string' === typeof value && '' !== value) ||
+        'function' === typeof value);
+}
+function validateGitTarget(target, location) {
+    if (!isObject(target) || !isTemplate(target.repository)) {
+        throw new ValidationError(`wp-release config ${location} must be an object with a repository URL template or callback.`);
+    }
+    if (undefined !== target.branches &&
+        'boolean' !== typeof target.branches &&
+        (!Array.isArray(target.branches) ||
+            target.branches.some((item) => 'string' !== typeof item))) {
+        throw new ValidationError(`wp-release config ${location}.branches must be a boolean or an array of branch names.`);
+    }
+    if (undefined !== target.tag &&
+        false !== target.tag &&
+        ('string' !== typeof target.tag ||
+            !target.tag.includes('{version}'))) {
+        throw new ValidationError(`wp-release config ${location}.tag must be a template with {version}, or false.`);
+    }
+    validateMessage(target.message, location);
+    if (undefined !== target.history && 'boolean' !== typeof target.history) {
+        throw new ValidationError(`wp-release config ${location}.history must be a boolean.`);
+    }
+}
+function validateMessage(message, location) {
+    if (undefined !== message && !isTemplate(message)) {
+        throw new ValidationError(`wp-release config ${location}.message must be a template or a callback.`);
+    }
+}
+function validateSvnTarget(target, location) {
+    if (!isObject(target)) {
+        throw new ValidationError(`wp-release config ${location} must be an object.`);
+    }
+    validateMessage(target.message, location);
+    if (undefined !== target.slug && !isTemplate(target.slug)) {
+        throw new ValidationError(`wp-release config ${location}.slug must be a template or a callback.`);
+    }
+    for (const key of ['url', 'assetsDir', 'readme']) {
+        if (undefined !== target[key] &&
+            ('string' !== typeof target[key] || !target[key])) {
+            throw new ValidationError(`wp-release config ${location}.${key} must be a non-empty string.`);
+        }
+    }
 }
 function validateVersionDescriptor(descriptor, location, isTarget) {
     if ('object' !== typeof descriptor || null === descriptor) {

package/dist/changeset-dependents.d.ts

@@ -2,6 +2,7 @@ import type { ChangesetConfig, DependentsConfig } from './changeset-config.ts';
 import type { ChangedPackages, ConfiguredPackage } from './changeset-packages.ts';
 import type { Changeset, ChangesetPackage, ChangesetReleasePlan, PackageRelease } from './changesets.ts';
 import type { FileJournal } from './file-journal.ts';
+import type { ReleaseRepository } from './release-repository.ts';
 /**
  * A declared dependency of a package on another configured package.
  */
@@ -67,16 +68,26 @@ export declare function assertDependentsSourcesReleased(plan: ChangesetReleasePl
  * with its sources, which the release pull request already announces when
  * the changesets of the diff release one of them. Exempting its package
  * manifest pin change keeps the check from demanding an entry for what
- * versioning rewrites anyway; documentation and code changes still need
- * their own changesets.
+ * versioning rewrites anyway. Any other change, like documentation, code or
+ * another manifest field or dependency, still needs its own changeset.
  *
- * @param changed          Changed packages and their files.
- * @param changesetsInDiff Changesets added or changed by the diff.
- * @param packages         Discovered packages.
- * @param config           Repository release configuration.
- * @return Names of the packages whose only changes are manifests of released dependents.
+ * @param input                  Changes of the diff and the repository.
+ * @param input.changed          Changed packages and their files.
+ * @param input.changesetsInDiff Changesets added or changed by the diff.
+ * @param input.packages         Discovered packages.
+ * @param input.config           Repository release configuration.
+ * @param input.repository       Repository to read the base manifests from.
+ * @param input.since            Base ref of the diff, like origin/main.
+ * @return Names of the packages whose only changes are pins of released sources.
  */
-export declare function findBundledPinChanges(changed: ChangedPackages, changesetsInDiff: Changeset[], packages: ConfiguredPackage[], config: ChangesetConfig): Promise<Set<string>>;
+export declare function findBundledPinChanges(input: {
+    changed: ChangedPackages;
+    changesetsInDiff: Changeset[];
+    packages: ConfiguredPackage[];
+    config: ChangesetConfig;
+    repository: ReleaseRepository;
+    since: string;
+}): Promise<Set<string>>;
 /**
  * Check whether a changeset names a package.
  *

package/dist/changeset-dependents.js

@@ -1,5 +1,6 @@
 import { readFile, writeFile } from 'node:fs/promises';
 import path from 'node:path';
+import { isDeepStrictEqual } from 'node:util';
 import semverSatisfies from 'semver/functions/satisfies.js';
 import validRange from 'semver/ranges/valid.js';
 import { assertKnownPackages, globRegExp } from "./changeset-packages.js";
@@ -208,57 +209,118 @@ export async function assertDependentsSourcesReleased(plan, fullPlan, packages,
  * with its sources, which the release pull request already announces when
  * the changesets of the diff release one of them. Exempting its package
  * manifest pin change keeps the check from demanding an entry for what
- * versioning rewrites anyway; documentation and code changes still need
- * their own changesets.
+ * versioning rewrites anyway. Any other change, like documentation, code or
+ * another manifest field or dependency, still needs its own changeset.
  *
- * @param changed          Changed packages and their files.
- * @param changesetsInDiff Changesets added or changed by the diff.
- * @param packages         Discovered packages.
- * @param config           Repository release configuration.
- * @return Names of the packages whose only changes are manifests of released dependents.
+ * @param input                  Changes of the diff and the repository.
+ * @param input.changed          Changed packages and their files.
+ * @param input.changesetsInDiff Changesets added or changed by the diff.
+ * @param input.packages         Discovered packages.
+ * @param input.config           Repository release configuration.
+ * @param input.repository       Repository to read the base manifests from.
+ * @param input.since            Base ref of the diff, like origin/main.
+ * @return Names of the packages whose only changes are pins of released sources.
  */
-export async function findBundledPinChanges(changed, changesetsInDiff, packages, config) {
+export async function findBundledPinChanges(input) {
+    const { changed, changesetsInDiff, packages, config, repository, since } = input;
     const candidates = changed.packages.filter((pkg) => undefined !== config.dependents &&
         !hasChangeset(changesetsInDiff, pkg.name) &&
-        (changed.filesByPackage[pkg.name] ?? []).every((file) => 'package.json' === path.basename(file)));
+        (changed.filesByPackage[pkg.name] ?? []).every((file) => repository.relativePath(manifestFile(pkg)) === file));
     const bundled = await Promise.all(candidates.map(async (pkg) => {
-        const sources = await collectDeclarationNames(pkg, packages, config);
-        return sources.some((source) => hasChangeset(changesetsInDiff, source))
-            ? pkg.name
-            : undefined;
+        const identifiers = await collectReleasedIdentifiers(pkg, packages, config, changesetsInDiff);
+        const pinsOnly = identifiers.length > 0 &&
+            (await changesOnlyPins({
+                pkg,
+                identifiers,
+                sections: dependentsSections(config.dependents),
+                repository,
+                since,
+            }));
+        return pinsOnly ? pkg.name : undefined;
     }));
     return new Set(bundled.filter((name) => undefined !== name));
 }
 /**
- * Check whether a changeset names a package.
+ * Collect the identifiers that a package declares for the configured sources
+ * released by the changesets, by the dependency sections of the policy,
+ * without resolving the specs against the versions. The changeset check uses
+ * this to see through a pin that the versioning will rewrite after the
+ * source releases.
  *
- * @param changesets Changesets.
- * @param name       Package name.
- * @return Whether one of the changesets names the package.
+ * @param pkg        Planned package.
+ * @param packages   Discovered packages.
+ * @param config     Repository release configuration.
+ * @param changesets Changesets that release the sources.
+ * @return Declared identifiers of the released sources, like npm package names.
  */
-export function hasChangeset(changesets, name) {
-    return changesets.some((changeset) => Object.hasOwn(changeset.packages, name));
+async function collectReleasedIdentifiers(pkg, packages, config, changesets) {
+    const identifiers = [];
+    for (const source of packages) {
+        const specs = pkg.name !== source.name && hasChangeset(changesets, source.name)
+            ? await findNpmSpecs(pkg, source, dependentsSections(config.dependents))
+            : [];
+        identifiers.push(...specs.map(({ name }) => name));
+    }
+    return identifiers;
 }
 /**
- * Collect the names of the configured sources that a package declares, by the
- * dependency sections of the policy, without resolving the specs against the
- * versions. The changeset check uses this to see through a pin that the
- * versioning will rewrite after the source releases.
+ * Check whether the package manifest differs from the base only in the specs
+ * of the given identifiers. A manifest that the diff adds has no base and
+ * always counts as a change of its own.
  *
- * @param pkg      Planned package.
- * @param packages Discovered packages.
- * @param config   Repository release configuration.
- * @return Release package names the package declares.
+ * @param input             Package, identifiers and the repository.
+ * @param input.pkg         Changed package.
+ * @param input.identifiers Declared identifiers whose specs may differ.
+ * @param input.sections    Dependency sections of the policy.
+ * @param input.repository  Repository to read the base manifest from.
+ * @param input.since       Base ref of the diff, like origin/main.
+ * @return Whether only the specs of the identifiers changed.
  */
-async function collectDeclarationNames(pkg, packages, config) {
-    const names = [];
-    for (const source of packages) {
-        if (pkg.name !== source.name &&
-            (await findNpmSpecs(pkg, source, dependentsSections(config.dependents))).length > 0) {
-            names.push(source.name);
+async function changesOnlyPins(input) {
+    const { pkg, identifiers, sections, repository, since } = input;
+    const base = await repository.readFileAtMergeBase(since, manifestFile(pkg));
+    const head = await readJsonIfExists(manifestFile(pkg));
+    return (undefined !== base &&
+        undefined !== head &&
+        isDeepStrictEqual(withoutSpecs(JSON.parse(base), sections, identifiers), withoutSpecs(head, sections, identifiers)));
+}
+/**
+ * Copy a manifest without the specs of the given identifiers in the
+ * dependency sections.
+ *
+ * @param manifest    Parsed package manifest.
+ * @param sections    Dependency sections.
+ * @param identifiers Declared identifiers to drop.
+ * @return Manifest copy without those specs.
+ */
+function withoutSpecs(manifest, sections, identifiers) {
+    const stripped = { ...manifest };
+    for (const section of sections) {
+        const specs = manifest[section];
+        if ('object' === typeof specs && null !== specs) {
+            stripped[section] = Object.fromEntries(Object.entries(specs).filter(([name]) => !identifiers.includes(name)));
         }
     }
-    return names;
+    return stripped;
+}
+/**
+ * The npm manifest of a package.
+ *
+ * @param pkg Package.
+ * @return Absolute manifest path.
+ */
+function manifestFile(pkg) {
+    return path.join(pkg.directory, 'package.json');
+}
+/**
+ * Check whether a changeset names a package.
+ *
+ * @param changesets Changesets.
+ * @param name       Package name.
+ * @return Whether one of the changesets names the package.
+ */
+export function hasChangeset(changesets, name) {
+    return changesets.some((changeset) => Object.hasOwn(changeset.packages, name));
 }
 /**
  * Collect the names of the configured sources that a package builds against,