@wpelevator/wp-release 0.12.0 → 0.14.0

package/README.md

@@ -28,12 +28,14 @@ npx wp-release --help
 |---|---|
 | `wp-release zip [<source-dir>] [options]` | Create a ZIP archive with a `{slug}/` root folder, respecting `.distignore`. |
 | `wp-release checksums [<source-dir>] [options]` | Write the MD5 and SHA-256 hashes of every distributed file to a checksums manifest. |
-| `wp-release sign <file>... [options]` | Sign files with Ed25519, writing a detached `<file>.sig` next to each. |
-| `wp-release keygen` | Generate a base64 Ed25519 private seed and public key for signing and verification. |
+| `wp-release sign <file>... [options]` | Sign files with Ed25519, writing a detached `<file>.sig` next to each, or minisign and SSH signatures with `--format`. |
+| `wp-release keygen` | Generate a base64 Ed25519 private seed and its public key, also as minisign and SSH public keys. |
 | `wp-release verify [<source-dir>] --checksums <file> [options]` | Check a plugin or theme directory, or a ZIP, against a checksums manifest. |
 | `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. |
@@ -65,19 +67,20 @@ Each command also adds a section to the [job summary](https://docs.github.com/en
 | `deploy-git` | Repository, release commit and the pushed branch and tag. |
 | `zip` | ZIP, number of files and checksums manifest. |
 | `checksums` | Manifest and number of files. |
-| `sign` | Signature files and the public key. |
+| `sign` | Signature files and the public key of each written format. |
 | `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. |
 
 A failed command adds its error to the summary, or a table of its problems with their files and lines, listing up to 100 and counting the rest. The Markdown of the summaries isn't part of the library API. File paths are relative to `GITHUB_WORKSPACE`, or the current directory without it. Files outside it, like those of an extracted ZIP, get an annotation without a file. Multi-line messages stay one annotation.
 
-Use global `--config <path>` to select a config; relative paths resolve from the current directory. Otherwise, Changesets commands discover `wp-release.config.js`, `.mjs` or `.cjs` there.
+Use global `--config <path>` to select a config; relative paths resolve from the current directory. Otherwise, Changesets commands discover `wp-release.config.js`, `.mjs` or `.cjs` there. Global `--tag-format <format>` replaces the `tagFormat` of the config for one command, see [Packages and tags](#packages-and-tags).
 
 ### 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:
 
@@ -122,13 +125,36 @@ 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.
+`version.from` selects the current version; `version.to` lists release targets. 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.
+#### Packages and tags
 
-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.
+The config describes the repository, so wp-release assumes no directory structure or naming convention of its own:
 
-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.
+- **Packages** are the directories that the `glob` of a `packages` entry matches under `root`, with `*`, `?` and `**`, like `plugins/*`, or `.` for a repository with one package at its root. The settings of an entry apply to each of its packages. Discovery never looks inside `.git`, `node_modules`, `vendor` or `dist` directories. A package is identified by its path, or with `idFrom` by the name in its `package.json` or `composer.json`, and commands that take a package accept either.
+- **Templates** name the tags and the deploy targets of a package with these placeholders:
+
+  | Placeholder | Value | `plugins/alpha` | Root package |
+  |---|---|---|---|
+  | `{path}` | Package directory relative to `root`, empty for a package at the root | `plugins/alpha` | (empty) |
+  | `{name}` | Package identifier | `plugins/alpha`, or its manifest name with `idFrom` | the manifest name, or the directory name |
+  | `{version}` | Released version | `1.2.0` | `1.2.0` |
+
+  Deploy templates also have `{branch}`, `{ref}` and `{revision}` (see [Deploy configured packages](#deploy-configured-packages)), and any template can be a callback that receives the package, for names that the placeholders don't cover, like the last directory of the path.
+- **`tagFormat`** names the release tags, `{path}/{version}` by default, like `plugins/alpha/1.2.0`. Empty placeholders leave no leading or repeated slashes in a tag, so a package at the root gets plain version tags, like `1.2.0`, from the same default. Deploy templates, like repository URLs, are filled in as they are. A `gitTagVersion()` version source reads the tags with its own `pattern`, also `{path}/{version}` by default, so set both when you change the format.
+- **`--tag-format <format>`** replaces the `tagFormat` of the config for one command, for a workflow or job that names its tags differently, like `--tag-format '{name}@{version}'`. Every command that creates or reads the same tags needs the same format: `changeset-tag`, which creates them and finds the previous tag for the release notes, `changeset-version --prerelease`, which numbers pre-releases from them, and `deploy-git` and `deploy-svn --release-ref`, which read the package and version of a tag.
+- **Slugs** are a WordPress concept: the folder of a plugin or theme. Only the commands that produce something for WordPress use one: the `{slug}/` root folder and name of a `zip`, the `checksums` manifest, the WordPress.org slug of `deploy-svn`, and `version-check`. Each takes `--slug`, which defaults to the name of the current directory, or of the package directory with `zip --package`, and an SVN deploy target takes `slug`, which defaults to the name of the package directory. Tags and Git deploy targets don't have a slug.
+- **`remote`** is the git remote that `changeset-tag --push` pushes tags to and that the base branch is compared on, `origin` by default.
+
+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 `<remote>/<baseBranch>`, where `remote` in the config defaults to `origin` and is also the remote that `changeset-tag --push` pushes tags to; 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`. In a terminal, it lists the packages, marks the ones that changed since `<remote>/<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.
 
@@ -152,6 +178,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
@@ -203,10 +231,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:
@@ -274,6 +329,7 @@ wp-release zip dist --slug my-plugin --checksums
 - Entries are sorted and use a fixed timestamp and file mode, so the same files always give the same ZIP.
 - `--checksums` also writes the [checksums manifest](#checksums) of the archived files next to the ZIP, with `.checksums.json` instead of `.zip`.
 - An existing ZIP or manifest isn't overwritten without `--force`. A ZIP or manifest written inside the source directory is never archived.
+- `--package <name>` zips a package of the [configured packages](#deploy-configured-packages), by identifier or path under the configured root like `plugins/alpha`, instead of a source directory: its directory with the `files` config of its package group, the same files that its deploys select. The slug defaults to the directory name and the version to the `Version` header, and `--slug` and `--version` still set them. Any package of the config works, with or without a version or deploy targets. To zip what a deploy just released, pass the `package` and `version` of the `deploy-git --release-ref` result, in the same job and from the same build, so the ZIP has exactly the files of the release tag in the release repository. It can't be combined with `<source-dir>` or the file selection options. The `--json` result has the `package`, `slug` and `version`. `zipPackage()` builds the same ZIP from a script, with `getPackageFiles()` for the directory and the files of a package.
 
 ### Checksums
 
@@ -316,9 +372,9 @@ wp-release verify wp-content/plugins/my-plugin --checksums my-plugin.1.2.0.check
 - Manifest paths outside the package folder (absolute or with `..`) are rejected.
 - `--zip <file|url>` checks the files of a ZIP instead of a directory. The ZIP can be a URL, such as the one that WordPress.org builds for a release, and its single root folder is found automatically (or set `--root-folder`). The ZIP is extracted to a temporary directory after the same safety checks as `deploy-svn --from-zip`.
 - The version in the manifest must match the `Version` header of the checked files, so that an older release with its own valid manifest can't pass as a newer one.
-- A manifest can't list itself. A copy of the manifest and of its `.sig` inside the checked files, at the root with the same names as the `--checksums` file or at the path of `--embedded`, is skipped when comparing files, but it must be identical to the `--checksums` file and its `.sig`. A path that the manifest lists is never skipped, and a file that isn't a matching copy is reported as not in the checksums. See [Manifest inside the plugin](#manifest-inside-the-plugin).
+- A manifest can't list itself. A copy of the manifest and of its signature inside the checked files, at the root with the same names as the `--checksums` file or at the path of `--embedded`, is skipped when comparing files, but it must be identical to the `--checksums` file and its signature. The signature is the `.sig` file, or the file of `--signature-format`. A path that the manifest lists is never skipped, and a file that isn't a matching copy is reported as not in the checksums. See [Manifest inside the plugin](#manifest-inside-the-plugin).
 
-A checksums manifest proves only that the files match the manifest. With `--public-key <key>`, `verify` first checks `<checksums>.sig` against the base64 Ed25519 public key and fails with exit code `2` before comparing any file when the signature is missing or invalid, so that the manifest itself can be trusted. See [Sign](#sign).
+A checksums manifest proves only that the files match the manifest. With `--public-key <key>`, `verify` first checks `<checksums>.sig` against the Ed25519 public key and fails with exit code `2` before comparing any file when the signature is missing or invalid, so that the manifest itself can be trusted. `--signature-format minisign` or `ssh` checks `<checksums>.minisig` or `<checksums>.sshsig` instead. The key can be the base64 key, the minisign public key or the `ssh-ed25519` public key, since they're forms of the same key. See [Sign](#sign).
 
 ### Manifest inside the plugin
 
@@ -331,7 +387,7 @@ wp-release zip build --slug my-plugin
 wp-release deploy-svn build --trunk --svn-tag 1.2.0
 ```
 
-- Write the manifest into the directory that is zipped and deployed. It lists every file except itself, and `checksums`, `zip` and `verify` also skip its `<name>.sig`, so running `checksums` again on a build that already has the pair gives the same manifest. Sign it last, since the signature covers the exact bytes of the manifest.
+- Write the manifest into the directory that is zipped and deployed. It lists every file except itself, and `checksums`, `zip` and `verify` also skip its signatures (`<name>.sig`, `<name>.minisig` and `<name>.sshsig`), so running `checksums` again on a build that already has the pair gives the same manifest. Sign it last, since the signature covers the exact bytes of the manifest.
 - `zip` and `deploy-svn` carry the pair like any other file. Don't use `zip --checksums` here, since it would write a second manifest that lists the first one. Attach `build/checksums.json` and `build/checksums.json.sig` to the GitHub release as they are.
 - The signature covers file hashes and not a ZIP, so it stays valid for the ZIP that WordPress.org builds from SVN. Check what WordPress.org serves after a deploy, with the manifest and public key from your build:
 
@@ -340,7 +396,7 @@ wp-release deploy-svn build --trunk --svn-tag 1.2.0
     --checksums build/checksums.json --public-key "$PUBLIC_KEY"
   ```
 
-- The manifest can have any name and location, for example `--output build/includes/signatures/checksums.json`, and missing folders are created. Tell `verify` where the shipped copy is with `--embedded <path>`, like `--embedded includes/signatures/checksums.json`. Both the `--checksums` file and its `.sig` must then exist, both copies must be shipped, and they're skipped when comparing files and must be identical to the originals. The manifest can't list the embedded path. Without `--embedded`, `verify` looks for the manifest name at the root, and skips a file only when it exists, the matching original exists and the manifest doesn't list it. Otherwise it's checked like any other file, so a listed file that has the name of the manifest can't be deleted unnoticed, and a shipped `.sig` without an original is reported as not in the checksums.
+- The manifest can have any name and location, for example `--output build/includes/signatures/checksums.json`, and missing folders are created. Tell `verify` where the shipped copy is with `--embedded <path>`, like `--embedded includes/signatures/checksums.json`. Both the `--checksums` file and its signature must then exist, both copies must be shipped, and they're skipped when comparing files and must be identical to the originals. The manifest can't list the embedded path. Without `--embedded`, `verify` looks for the manifest name at the root, and skips a file only when it exists, the matching original exists and the manifest doesn't list it. Otherwise it's checked like any other file, so a listed file that has the name of the manifest can't be deleted unnoticed, and a shipped `.sig` without an original is reported as not in the checksums.
 
 The public key has to come from somewhere other than the plugin that it checks, because someone who can overwrite the plugin files can also replace a key and a signature inside them. A copy of the manifest also doesn't prevent a downgrade to an older release that was signed too, so the installing side has to enforce a minimum version.
 
@@ -356,10 +412,28 @@ WP_RELEASE_SIGNING_KEY=… wp-release sign my-plugin.1.2.0.zip my-plugin.1.2.0.c
 
 - The signature is the one WordPress core's `verify_file_signature()` checks: a base64 Ed25519 signature of the raw SHA-384 digest of the file. The tests check it against `sodium_crypto_sign_verify_detached()` in PHP. A `.sig` file can hold several signatures, one per line, and a file is valid when any of them match, which allows a key rotation window.
 - The key is read from the `WP_RELEASE_SIGNING_KEY` environment variable only, as a base64 32-byte Ed25519 seed or a 64-byte libsodium secret key, the formats that `sodium_crypto_sign_seed_keypair()` and the update-pilot-server package signing key take. There's no flag for it, since it would show in the process list, and it's never logged.
-- `--verbose` prints the public key of the signing key, which `--json` also returns as `publicKey`. Pass it to `verify --public-key` and to the plugin that checks the signatures.
-- An existing `.sig` file isn't overwritten without `--force`.
+- `--verbose` prints the public key of the signing key in the form of each written format. `--json` returns it as `publicKey`, and in every form as `publicKeys`. Pass it to `verify --public-key` and to the plugin that checks the signatures.
+- An existing signature file isn't overwritten without `--force`.
+
+#### Signature formats
 
-Generate a key pair with `wp-release keygen`. It prints the private seed once as `WP_RELEASE_SIGNING_KEY=…` and the matching public key. Store the private seed securely; never commit it or put it in a workflow log. Don't run `keygen` in CI or with `--github-output`, since those outputs can expose the private seed. The public key can be distributed to verifiers.
+The same key can also sign in formats that tools outside WordPress check, for people who download a release by hand or verify it in other pipelines. Pick them with `--format`, comma-separated or repeated; the default is `wordpress`:
+
+```bash
+wp-release sign my-plugin.1.2.0.zip --format wordpress,minisign,ssh
+```
+
+| Format | File | Checked by |
+|---|---|---|
+| `wordpress` | `<file>.sig` | WordPress core's `verify_file_signature()`, update-client and `wp-release verify` |
+| `minisign` | `<file>.minisig` | [minisign](https://jedisct1.github.io/minisign/) and compatible tools: `minisign -Vm <file> -P <minisign public key>` |
+| `ssh` | `<file>.sshsig` | OpenSSH 8.1 or later: `ssh-keygen -Y verify -f allowed_signers -I <identity> -n file -s <file>.sshsig < <file>` |
+
+- `minisign` signs the BLAKE2b-512 digest of the file, like `minisign -S` does by default, and adds a trusted comment with the signing time and file name that a second signature covers. minisign generates a random key ID for its keys, but the key here is a plain Ed25519 seed, so wp-release derives the key ID from the public key. `wp-release verify` doesn't compare key IDs, so signatures of keys that minisign generated verify too.
+- `ssh` is the armored `SSHSIG` format that `ssh-keygen -Y sign` writes, with a SHA-512 digest and the `file` namespace, so that the signature can't pass as one for commits or another namespace. It's written to `.sshsig` instead of the `.sig` of `ssh-keygen`, which the `wordpress` format uses. Put the SSH public key in an `allowed_signers` file as `<identity> ssh-ed25519 AAAA…`.
+- All formats are Ed25519 signatures by the same key, so one key and one secret cover all of them. The tests check each format with `minisign`, `ssh-keygen` and libsodium, and check the signatures that `minisign` and `ssh-keygen` write with `wp-release verify`.
+
+Generate a key pair with `wp-release keygen`. It prints the private seed once as `WP_RELEASE_SIGNING_KEY=…` and the matching public key, also as a minisign public key and an `ssh-ed25519` public key. Store the private seed securely; never commit it or put it in a workflow log. Don't run `keygen` in CI or with `--github-output`, since those outputs can expose the private seed. The public key can be distributed to verifiers.
 
 ### Version check
 
@@ -456,7 +530,55 @@ 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: ( { package: pkg } ) => `https://github.com/me/${ pkg.path.split( '/' ).pop() }.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: ( { package: pkg } ) => `me-${ pkg.path.split( '/' ).pop() }`, 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`, the WordPress.org plugin slug, defaults to the name of the package directory, `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}` and `{path}`, 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 name a target after the package directory, 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.
+- **Results**: with `--json` or `--github-output`, the result lists each deploy in `deploys` with its `package`, `label`, `target` (the repository or WordPress.org plugin, with credentials redacted), `targetRef` (the tag or branch written there), `version` or `branch`, and its `result` or `error`. A remote target repository also has its `targetHost`, like `github.com`, and `targetPath`, like `me/my-plugin`, without credentials, for a workflow step that calls the API of the forge that hosts it, such as to create the release of the deployed tag. The targets of `--list` have the same `host` and `path`, and `parseRepositoryUrl()` reads them from an HTTP(S), SSH or scp-like URL. `wp-release` doesn't call forge APIs itself.
+- **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. `zip --package <name>` zips a package with the same files, `getPackageFiles()` returns the directory and the file selection of any configured package, and `getDeployPackages()` lists the packages with deploy targets and their file selection.
+
+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
 
@@ -627,6 +749,13 @@ The `wpelevator-source` export condition points at `src/index.ts`. The tests and
 
 ### Architecture
 
+wp-release has two layers, so that it fits any repository layout:
+
+- **Primitives** work on the directory, file or values they're given and know nothing about the repository: `zip <dir>`, `checksums`, `sign`, `verify`, `version-check`, `deploy-git <dir>` and `deploy-svn <dir>`.
+- **The config layer** reads `wp-release.config.js` for everything about the repository: where packages are (`root` and the package globs), how their versions and tags are named (`version`, `tagFormat`), which files they ship (`files`), where they deploy (`deploy`) and the git `remote`. The changeset commands, `deploy-git` and `deploy-svn --release-ref`, and `zip --package` belong to it, and the global `--config` and `--tag-format` options select or adjust the config. Only `--release-ref` reads which package and version a ref releases. A primitive with a config mode, like `deploy-git --release-ref` beside `deploy-git <dir>` or `zip --package` beside `zip <dir>`, only takes the package directory, its files and its targets from the config there, and otherwise works the same.
+
+Nothing assumes a directory structure or naming convention that the config doesn't set.
+
 The package uses ES modules as its unit of encapsulation, like most Node.js CLI tools: a module exports a few functions and keeps its helpers private, so there's no class to wrap them in. A class is used only when it holds state across steps or binds dependencies, so that callers and tests can replace them:
 
 - **Workflows with steps** are classes, so that their steps share state and dependencies on the instance: `SvnDeploy` shares the temporary working copy across `prepare()`, `checkout()`, `sync()` and `commit()`, `GitDeploy` binds the options and the git runner to its steps, and `ChangesetRelease` binds the repository and the runners to `add()`, `version()` and `tag()`.
@@ -641,7 +770,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. |
@@ -649,6 +778,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`, and the file selection of a package for `zip --package`. |
+| `package-zip.ts` | `zipPackage()`, the ZIP and checksums manifest of the selected files of a package, for `zip` and the snapshot builds of a monorepo. |
 | `release-repository.ts` | `ReleaseRepository`, the git commands of a release: tags, commits and changed files. |
 | `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

@@ -62,12 +62,85 @@ export interface ChangesetPackageGroup {
     glob: string;
     /** Package paths excluded from this group, relative to root. */
     exclude?: string[];
-    /** Optional type used by the {type} tag template. */
-    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}, {path},
+ * {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/{path}.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 {
+    /** WordPress.org plugin slug, defaults to the name of the package directory. */
+    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 {
@@ -146,11 +219,13 @@ export interface DependentsConfig {
 export interface ChangesetConfig {
     /** Branch receiving ordinary changes. */
     baseBranch?: string;
+    /** Git remote that tags are pushed to and the base branch is compared on, origin by default. */
+    remote?: string;
     /** Directory containing Markdown changesets, relative to the repository root. */
     changesets?: string;
     /** Package groups to discover and release. */
     packages: ChangesetPackageGroup[];
-    /** Git tag template supporting {name}, {slug}, {path}, {type} and {version}. */
+    /** Git tag template supporting {name}, {path} and {version}. */
     tagFormat?: string;
     /** Directory against which package paths in tag formats are calculated. */
     root?: string;
@@ -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 {
@@ -281,6 +358,8 @@ export declare function defineConfig(config: ChangesetConfig): ChangesetConfig;
 export interface LoadChangesetConfigInput {
     cwd?: string;
     configFile?: string;
+    /** Tag format that replaces the tagFormat of the config, like from --tag-format. */
+    tagFormat?: string;
 }
 /**
  * Load and validate the repository's JavaScript wp-release configuration.
@@ -293,3 +372,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

@@ -138,7 +138,12 @@ export async function loadChangesetConfig(input = {}) {
         ? loaded.default
         : undefined;
     validateChangesetConfig(config, configFile);
-    return { config, file: configFile };
+    return {
+        config: input.tagFormat
+            ? { ...config, tagFormat: input.tagFormat }
+            : config,
+        file: configFile,
+    };
 }
 async function findConfigFile(cwd) {
     for (const fileName of CONFIG_FILES) {
@@ -171,6 +176,7 @@ function validateChangesetConfig(config, configFile) {
     }
     for (const [key, value] of Object.entries({
         baseBranch: candidate.baseBranch,
+        remote: candidate.remote,
         changesets: candidate.changesets,
         changelogInsertAfter: candidate.changelogInsertAfter,
         root: candidate.root,
@@ -250,13 +256,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 &&
@@ -266,19 +274,108 @@ function validateChangesetConfig(config, configFile) {
         if ('string' !== typeof group.glob || !group.glob.trim()) {
             throw new ValidationError(`wp-release config ${configFile} packages[${index}].glob must be a non-empty string.`);
         }
-        if ('string' !== typeof group.tagType &&
-            undefined !== group.tagType) {
-            throw new ValidationError(`wp-release config ${configFile} packages[${index}].tagType must be a string.`);
-        }
         if (undefined !== group.exclude &&
             (!Array.isArray(group.exclude) ||
                 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) {
         throw new ValidationError(`wp-release config ${location} must be an object.`);