Tools for managing the package lifecycle

Motivation

The feature "support for the dedicated release branch flow" will require support for package management in Beachball. Version and changelog updates must be managed when altering package structure. If Beachball is not aware of the package lifecycle, changelogs and versions on the release branch may be lost or left in the orphan state.

Proposal

Following package operations must be supported:

• Deleting a package
• Renaming a package
• Merging two or more packages
• Splitting a package into two or more packages

Deleting a package

On package deletion, version bumping must also delete the changelog from the release branch. Change file:

"delete": true,

Rename package

On version bump, the package must be moved from old to new package name in the release branch. Version level is patch iterated from the original branch. Change file:

"renameFrom": "@contoso/logToScreen",

Merging packages

Rename existing changelogs into: CHANGELOG_.json|md . Example: + CHANGELOG_logger.json . Highest version from merged packages is patch level iterated. Change file:

"mergedFrom": ["@contoso/logToScreen", "@contoso/logToConsole"],

Splitting package

Copy changelog into new packages. A version from the original package is patch level iterated. Change file:

"splitFrom": ["@contoso/logToScreen"]

Indicating change

Add option to beachball change command for the four lifecycle events, rename, delete, merge, and split. Example: beachball change delete <package name> . This will cause beachball change to add JSON options listed above.

cc: @khovik, @VincentBailly, @bweggersen

Start with the beachball change command and the dedicated release branch flow described in issue 361. Trace how change files and changelogs are handled, then verify that rename, delete, merge, and split operations produce the specified options and preserve the required versions and changelogs.