Changesets

pubm utilise les changesets comme l’enregistrement durable de ce qui doit être publié ensuite. Au lieu de déduire les versions à partir des messages de commit ou des noms de branche, il lit les fichiers versionnés dans .pubm/changesets/ et les transforme en changements de version et en entrées de changelog.

Pourquoi les changesets sont utiles

• un plan de release relisible dans chaque pull request
• un calcul déterministe des changements de version sur plusieurs packages
• un contenu de changelog écrit avant le jour de la release, pas après

Emplacement des fichiers

Les changesets en attente se trouvent dans :

.pubm/changesets/

Initialisez ce répertoire en lançant l’assistant de configuration interactif :

pubm init

Pendant la configuration, pubm init demande si vous souhaitez activer le workflow de changesets. Répondre oui crée le répertoire .pubm/changesets/, génère .github/workflows/changeset-check.yml pour l’application en PR, et met à jour .gitignore pour suivre les fichiers changeset tout en ignorant les autres contenus de .pubm/.

Créer un changeset

pubm changesets add

Dans un monorepo, pubm demande aussi quels packages sont concernés et quel type de changement chacun doit recevoir.

Pour un usage non interactif :

pubm changesets add \
  --packages @acme/core,@acme/react \
  --bump minor \
  --message "Add token-based auth to the public client."

Contenu d’un fichier changeset

---
"@acme/core": minor
"@acme/react": patch
---

Add token-based auth to the public client.

Les métadonnées contrôlent le calcul de version. Le corps devient le résumé du changelog.

Inspecter les changements en attente

Avant de consommer les changesets, inspectez-les :

pubm changesets status
pubm changesets status --verbose
pubm changesets version --dry-run

Comment les changesets sont consommés

Quand vous lancez le pipeline de release normal avec pubm, les changesets en attente sont consommés pendant l’étape de version.

Ce flux :

1. lit les fichiers .pubm/changesets/*.md en attente
2. calcule les versions finales des packages
3. met à jour les versions dans les manifests
4. génère les entrées de changelog
5. supprime les fichiers changeset consommés
6. crée le commit de release et les tags

Si vous voulez effectuer uniquement la partie versioning à l’avance, vous pouvez toujours exécuter :

pubm changesets version

Cette commande est utile pour les workflows éditoriaux ou contrôlés, mais elle n’est pas nécessaire avant pubm ou pubm --mode ci --phase publish.

Génération du changelog

Si vous voulez générer le texte du changelog sans encore consommer les versions :

pubm changesets changelog --dry-run
pubm changesets changelog --version 1.8.0

Repli sur les commits conventionnels

Lorsque versionSources est "all" (la valeur par défaut), pubm changesets version revient automatiquement aux commits conventionnels pour tout package sans fichier de changeset en attente. Cela permet aux équipes d’adopter les changesets progressivement : les packages avec changesets les utilisent ; les packages sans changesets se replient sur l’historique des commits.

Correspondance par défaut des types de commits

Type de commit	Bump
feat	minor
fix	patch
perf	patch

Un footer BREAKING CHANGE ou un suffixe ! (ex. feat!:) produit toujours un bump major.

Configurer des correspondances personnalisées

Remplacez la correspondance par défaut dans pubm.config.ts :

export default defineConfig({
  versionSources: "all",
  conventionalCommits: {
    types: {
      feat: "minor",
      fix: "patch",
      perf: "patch",
      docs: "patch",
    },
  },
});

Définissez versionSources: "commits" pour n’utiliser que les commits conventionnels et ignorer complètement les fichiers de changeset. Définissez versionSources: "changesets" pour désactiver le repli et n’utiliser que les fichiers de changeset.

Migration depuis .changeset/

pubm changesets migrate

Cela migre les fichiers en attente de .changeset/ vers .pubm/.