Changesets vs semantic-release: Releases para monorepos no CI
O Changesets usa arquivos de mudança explícitos e escritos (ótimo para monorepos); o semantic-release deriva tudo automaticamente de Conventional Commits.
No Changesets, os contribuidores adicionam um pequeno arquivo de changeset por mudança descrevendo o bump; um PR de release então versiona e publica os pacotes afetados - forte para monorepos. O semantic-release infere versões e publica automaticamente a partir das mensagens de commit.
| Changesets | semantic-release | |
|---|---|---|
| Fonte do versionamento | Arquivos de changeset escritos | Conventional Commits |
| Suporte a monorepo | First-class (por pacote) | Possível, mais setup |
| Fluxo de release | PR de release (revisão) | Automático no push |
| Esforço do contribuidor | Adicionar um changeset | Escrever commits em conformidade |
| Melhor para | Monorepos, bumps intencionais | Pacotes únicos, automação total |
No CI
O Changesets foi feito para monorepos: cada pacote é versionado e publicado a partir de arquivos de mudança explícitos via um PR de release, dando controle preciso por pacote e um gate de revisão. O semantic-release é melhor para pacotes únicos e publicação totalmente automatizada a partir de commits. Se você mantém muitos pacotes em um repo, o Changesets geralmente se encaixa melhor; para um pacote sem etapa de revisão, o semantic-release é mais simples.
Setup de CI
Dê ao job de release tokens para publicar e versionar, e para monorepos faça cache e limite os builds aos pacotes afetados. O job de release roda nos runners de CI; runners gerenciados mais rápidos encurtam builds de release que empacotam ou compilam muitos pacotes.
O veredito
Monorepo querendo versionamento explícito por pacote com um gate de revisão: Changesets. Pacote único querendo releases totalmente automatizados e guiados por commits: semantic-release. Escolha pelas necessidades de monorepo e por quanta intenção manual você quer por release.