Changesets v3 reduz instalação em 88% e troca bump major por patch em peer deps

Sete anos depois do v2, a ferramenta de versionamento para monorepos JavaScript↳JavaScript116 conteúdosJavaScript em 2020: O que esperarDev (Back & Front) · jan 2020Campos públicos e privados em classes JavaScript – O que vem por aí no ESNextDev (Back & Front) · abr 201929 anos de JavaScript!Dev (Back & Front) · jan 2025Ver tudo em Dev (Back & Front) → virou ESM only, exige Node 22.11+ e muda um comportamento que gerava reclamação há anos.

O Changesets, ferramenta MIT usada para versionar pacotes e gerar changelogs em monorepos JavaScript, lançou sua v3.0 em 11 de agosto de 2026, a primeira major release em sete anos desde o v2. A liderança do projeto passou para um time formado por Mateusz Burzyński, Bjorn Lu e Adam Haglund, que conduziu a migração através de um plano público de release e hoje mantém mais de 3 milhões de downloads semanais no npm, segundo o anúncio no InfoQ.

Se você mexe com monorepo em TypeScript ou JavaScript, é bem provável que já tenha um arquivo .changeset no repositório sem nunca ter pensado muito nele. O Changesets é a peça que transforma a intenção de release escrita em markdown por um contribuidor em bump de versão, entrada de changelog e publish no registry, mantendo isso revisável dentro de um pull request. A v3 não muda esse modelo, mas mexe pesado em como ele roda e em uma regra de negócio que irritava times há anos.

Instalação 88% menor e Node 22.11 como piso

Todos os pacotes agora são ESM only, o que exige Node.js 22.11 ou mais recente, além de pnpm 10, npm 10.9 ou Yarn 4.5.2 como versões mínimas. O Yarn Classic foi descontinuado. Por trás dessa limpeza, o time trocou a base de build e teste para tsdown, rolldown, vitest e oxfmt, e isso derrubou o tamanho de instalação de 16,1MB para 2,1MB e o número de dependências de 95 para 39 (a conta de 88% de redução vem exatamente dessa comparação).

Outro efeito colateral da limpeza: o Changesets deixou de embutir sua própria cópia do Prettier para formatar changelogs. Agora existe o pacote @changesets/format, que detecta e usa Prettier, oxfmt, Deno ou dprint conforme o que já está configurado no projeto, evitando duplicar dependência de formatação.

Para quem roda pipeline de CI com cache de node_modules ou imagem de container fixa, isso é ganho direto de tempo de build e superfície de auditoria de supply chain menor, não é só estética de instalação mais rápida.

Peer dependency: de major para patch

A mudança de comportamento mais discutida é como o Changesets trata dependências peer. Antes, quando uma dependência peer levava um bump, todo pacote dependente dela recebia automaticamente um bump major, mesmo quando a mudança não quebrava nada na prática. Isso gerou anos de reclamação, documentada no issue 1011 do repositório, onde um time mantendo um design system↳Design system5 conteúdosComo desenvolvemos o novo Design System do AsaasProduto & UX · jul 2024UX e Código: Por que designers que conhecem programação têm uma vantagem estratégicaProduto & UX · abr 2025A importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Ver tudo em Produto & UX → em monorepo escreveu que forçar major nesse caso "parece estar enviando a mensagem errada e não respeitando o semver".

Na v3, um bump de peer dependency agora propaga como patch para os dependentes, não mais como major. Quem realmente está lançando uma quebra de compatibilidade continua podendo adicionar um changeset major explícito para o pacote dependente, mas o padrão deixou de assumir o pior cenário.

Nem todo mundo concorda que essa é a solução ideal. Os mantenedores do Bumpy, um concorrente lançado recentemente, apontam que a v3 "hardcoda o extremo oposto", já que agora toda mudança de peer é assumida como não destrutiva por padrão, e nenhuma das duas ferramentas permite configurar esse comportamento de propagação. Mesmo com essa ressalva, a comparação do próprio Bumpy reconhece que a v3 resolve queixas antigas, listando como lacunas remanescentes o suporte a catalog do pnpm e um design de prerelease que não mudou.

O que quebra na migração

A CLI foi reconstruída sobre cac para parsing de argumentos e clack para prompts interativos, o que resolve um bug conhecido de prompts cancelados derrubando o processo. Comandos e flags foram renomeados:

# v2
changeset tag
changeset status --sinceMaster

# v3
changeset git-tag
changeset status --since=main

A configuração também mudou: a chave prettier foi substituída por format, e pacotes privados deixaram de ser versionados por padrão, exigindo opt-in explícito:

{
 "format": "auto",
 "privatePackages": { "version": true, "tag": false }
}

Há também uma mudança de comportamento que pega quem automatiza tudo sem checar código de saída: changeset version agora retorna exit code 1 quando não há nada para liberar. Um playbook de release citado no InfoQ alerta que "qualquer script que rode isso incondicionalmente sob set -e vai falhar agora numa release vazia". Vale revisar pipelines que chamam changeset version direto num job de CI sem tratar esse caso.

Dois comandos novos, pack e publish-plan, dão suporte à sequência de build, pack e publish recomendada pela comunidade e18e, e o changesets/action também foi atualizado para v2, expondo sub-ações que permitem times usando trusted publishing do npm restringirem permissões de publicação por etapa, em vez de dar token amplo para o job inteiro.

Onde o Changesets ainda se diferencia

Contra o semantic-release, que infere a versão a partir de conventional commits, e o release-it, o Changesets mantém sua característica mais distintiva: quem contribui escreve a intenção de release num arquivo markdown, e essa decisão fica visível e revisável dentro do pull request antes de virar versão publicada. A v3 não mexe nesse modelo, ela só o torna mais barato de instalar e mais bem comportado em torno de peer dependencies.

Para quem mantém monorepo com múltiplos pacotes publicados no npm, o pacote de mudanças da v3 é essencialmente housekeeping bem-vindo: menos peso de instalação, menos ruído de major bump indevido e alguns comandos renomeados que exigem passar pelo guia de migração antes de atualizar o CI. A v2 segue mantida numa branch separada para quem não puder migrar de imediato para os requisitos mínimos de Node 22.11 e gerenciadores de pacote mais recentes.

Fonte: InfoQ