中文
devexamples
← Workflows

阅读中文版本

Monorepo Versioning Workflow

Define which packages are published, choose independent or fixed versioning, automate version bumps and changelogs, and publish in dependency order.

intermediate~90 minmonoreporeleaseversioning

Objective

Version and release a monorepo consistently whether packages version independently or together.

Environment

  • A monorepo with multiple packages
  • A versioning tool such as Changesets or Lerna

Steps

1. Classify packages as published, private,

Classify packages as published, private, or internal.

Expected state: The release surface is known.

2. Choose independent or fixed versioning

Choose independent or fixed versioning and document it.

Expected state: The versioning strategy is unambiguous.

3. Automate changelog generation and version bumps

Automate changelog generation and version bumps from change descriptions.

Expected state: Versions and notes stay consistent.

4. Publish in dependency order after

Publish in dependency order after the version PR merges.

Expected state: Dependents are released against published dependencies.

Decision points

Independent or fixed versioning?

  • Independent
  • Fixed

Independent for loosely coupled packages; fixed when consumers expect a shared version line.

Publish from CI or locally?

  • CI only
  • Either

CI only; local publishes bypass review and can leave versions inconsistent.

Expected outcome

Packages are versioned and published consistently, with changelogs derived from changes and dependency-ordered publishing.

Verification

Confirm that a change to a shared package triggers correct bumps and that publishing order respects the dependency graph.

Cleanup

Tag releases and record which packages were published in the run.

Overview

Version and release a monorepo consistently whether packages version independently or together. Confirm that a change to a shared package triggers correct bumps and that publishing order respects the dependency graph.

Steps

  1. Classify packages as published, private, or internal. Expected state: The release surface is known.
  2. Choose independent or fixed versioning and document it. Expected state: The versioning strategy is unambiguous.
  3. Automate changelog generation and version bumps from change descriptions. Expected state: Versions and notes stay consistent.
  4. Publish in dependency order after the version PR merges. Expected state: Dependents are released against published dependencies.
npx changeset version
npx changeset publish
# publish respects the workspace dependency graph

Verification

  • Packages are versioned and published consistently, with changelogs derived from changes and dependency-ordered publishing.

Decision points

  • Independent or fixed versioning? Options: Independent; Fixed. Recommended: Independent for loosely coupled packages; fixed when consumers expect a shared version line.
  • Publish from CI or locally? Options: CI only; Either. Recommended: CI only; local publishes bypass review and can leave versions inconsistent.