You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"comment": "Rename `canary` command to `prerelease`, repurpose `prereleasePrefix` (and remove `canaryName`), and shrink `ChangeType` to `patch | minor | major | none`. Old `pre*` change types in change files are auto-coerced (with a warning); `prerelease` change type is now an error. `bump`/`publish` no longer produce prerelease versions and now strip any prerelease component from the current version before bumping (prerelease → release promotion).",
Publishes a prerelease version (such as a canary, beta, or per-PR release) for the current change set, **without committing changes back to git or deleting change files**.
10
+
11
+
```bash
12
+
$ beachball prerelease
13
+
```
14
+
15
+
This command is useful for sharing prereleases of in-progress work — for example, a per-PR build that consumers can install to test changes before merging.
16
+
17
+
## How it works
18
+
19
+
For each package that has a change file (or that becomes modified due to dependency bumps), `beachball prerelease`:
20
+
21
+
1. Looks up the change type from the change files (just like `bump` and `publish`).
22
+
2. Computes the **target release version** by applying the change type to the current `package.json` version, after stripping any existing prerelease component. (For example, `0.2.0-beta.0` with a `minor` change type produces a target of `0.3.0`.)
23
+
3. Queries the npm registry for existing published versions that match `<target>-<prereleasePrefix>.<n>`, finds the highest counter `N`, and publishes `<target>-<prereleasePrefix>.<N+1>`.
24
+
4. Publishes to npm under the dist-tag matching `prereleasePrefix` (e.g. `beta`).
25
+
26
+
If no matching prerelease versions have been published yet, the counter starts from [`identifierBase`](#options).
27
+
28
+
The change files and `package.json` versions are **not** committed back to git. This means subsequent prerelease runs from the same change set will produce incrementing prerelease versions — useful for iterating on a PR without polluting git history.
| 1 | A developer creates a change file for a `minor` change to `foo`. |`change/foo-….json` exists; `foo` is at version `1.2.3`. |
35
+
| 2 | CI runs `beachball prerelease --prerelease-prefix pr30`. |`foo@1.3.0-pr30.0` is published with dist-tag `pr30`. |
36
+
| 3 | The developer pushes another commit to the PR; CI re-runs. |`foo@1.3.0-pr30.1` is published. |
37
+
| 4 | The PR is merged; main runs `beachball publish`. |`foo@1.3.0` is published with dist-tag `latest`, normal git commit. |
38
+
39
+
Step 4 above demonstrates the **prerelease-to-release promotion** behavior of `bump`/`publish`: when a package's current `package.json` version contains a prerelease component (such as if `prerelease` ran on the same branch as `publish` would later run), the prerelease component is stripped before applying the bump, so the user gets the intuitive target release version.
40
+
41
+
## Options
42
+
43
+
[General options](./options) also apply for this command.
44
+
45
+
<!-- prettier-ignore -->
46
+
| Option | Default | Description |
47
+
| ------ | ------- | ----------- |
48
+
|`--prerelease-prefix`|`'prerelease'`| Suffix used for the prerelease version, e.g. `"beta"` produces `1.2.3-beta.0`. The same value is used as the npm dist-tag. |
49
+
|`--identifier-base`|`'0'`| Starting counter for prereleases when no matching versions are published yet. `'0'` (default) starts at `.0`, `'1'` starts at `.1`, or `false` omits the numeric counter entirely (in which case re-running on the same target version will error). |
50
+
51
+
## Migrating from `beachball canary`
52
+
53
+
This command replaces the old `beachball canary` command. The previous `canaryName` option has been removed; use `prereleasePrefix` instead.
54
+
55
+
In addition, `bump` and `publish` no longer support producing prerelease versions directly. If you previously used `prereleasePrefix` with `bump`/`publish`, switch to `beachball prerelease` for prerelease publishing.
Copy file name to clipboardExpand all lines: docs/concepts/change-types.md
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,6 +38,12 @@ Packages with a major version of 0 are considered unstable per the semver spec.
38
38
39
39
Some repos or packages may restrict which change types are allowed using the [`disallowedChangeTypes`](../overview/configuration#options) config option. For example, `major` bumps are often disallowed to ensure coordination of major release efforts. Any disallowed options will be omitted from the interactive prompt, and a change file or `--type` argument that uses a disallowed type will cause an error.
40
40
41
+
## Prereleases
42
+
43
+
To publish a prerelease version (such as a canary, beta, or per-PR build), use the [`beachball prerelease`](../cli/prerelease) command. There is no `prerelease` change type — instead, choose one of `patch`, `minor`, `major`, or `none` based on the impact of your changes, and let `beachball prerelease` handle the prerelease versioning.
44
+
45
+
> **Note:** Older Beachball versions accepted `premajor`, `preminor`, `prepatch`, and `prerelease` as change types. These have been removed; existing change files using `premajor`/`preminor`/`prepatch` are auto-migrated to `major`/`minor`/`patch` (with a deprecation warning), and change files using `prerelease` will produce an error so they can be recreated with the appropriate type.
46
+
41
47
## Tips for reviewers
42
48
43
49
Change files show up as part of the PR diff, making it easy to verify the change type during code review. Common things to watch for:
Copy file name to clipboardExpand all lines: docs/overview/configuration.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -93,7 +93,7 @@ For the latest full list of supported options, see `RepoOptions` [in this file](
93
93
|`ignorePatterns`|`string[]`|| repo | Ignore changes in files matching these glob patterns ([see notes][6]) |
94
94
|`npmReadConcurrency`| number | 5 | repo | Maximum concurrency for fetching package versions from the registry (see `concurrency` for write operations) |
95
95
|`package`|`string`|| repo | Specifies which package the command relates to (overrides change detection based on `git diff`) |
96
-
|`prereleasePrefix`|`string`|| repo |Prerelease prefix, e.g. `"beta"`. Note that if this is specified, packages with change type major/minor/patch will be bumped as prerelease instead. |
96
+
|`prereleasePrefix`|`string`|`'prerelease'`| repo |Suffix used by the [`prerelease`](../cli/prerelease) command for prerelease versions, e.g. `"beta"` produces versions like `1.2.3-beta.0`. |
97
97
|`packStyle`|`'sequential' \| 'layer'`|`'sequential'`| repo | With `packToPath`, how to organize the tgz files. `'sequential'` uses numeric prefixes to ensure topological ordering. `'layer'` groups the packages into numbered subfolders based on dependency tree layers. |
98
98
|`packToPath`|`string`|| repo | Instead of publishing to npm, pack packages to tgz files under the specified path. |
99
99
|`publish`|`boolean`|`true`| repo | Whether to publish to npm registry |
0 commit comments