Quando Usar Monorepo: Multi-Package em Um Repo
Quando monorepo é produtivo e quando multi-repo é mais simples.
Por que isso é importante
Quando Usar Monorepo: Multi-Package em Um Repo. Quando monorepo é produtivo e quando multi-repo é mais simples.
Quando SIM usar Monorepo
Múltiplos projetos compartilham código
Web, mobile, admin usando mesmas libs. Monorepo permite imports diretos. Mudança em lib atualiza todos apps simultaneamente.
Você quer atomic changes cross-project
Mudar API e atualizar clientes em um PR. Sem monorepo são múltiplos PRs coordenados. Monorepo simplifica refactors grandes.
Time é pequeno e trabalha em tudo
Se mesmos devs tocam web, API, mobile, monorepo evita trocar de repo. Menos context switching, mais produtividade.
Versioning sincronizado é importante
Deploy de API e web deve ser coordenado. Monorepo garante que ambos estão em sync. Multi-repo exige tags e releases cuidadosas.
Você usa ferramentas modernas (Turborepo, Nx)
Ferramentas modernas resolvem problemas de monorepo (caching, task orchestration). Com tooling certo, monorepo escala bem.
Quando NÃO usar Monorepo
Projetos são completamente independentes
Se web e API não compartilham nada, monorepo é overhead. Multi-repo com versionamento separado é mais simples.
Times são isolados por projeto
Time A só toca projeto X, time B só projeto Y. Sem overlap. Monorepo adiciona complexidade sem benefício.
CI/CD não suporta builds seletivos
Sem tool como Nx, cada commit builda tudo. Lento demais. Se sua CI é simples, multi-repo é mais direto.
Repo vai ficar gigante (Git lento)
Monorepo com 100+ packages e anos de história fica lento. Git clone e operations demoram. Empresas usam VFS, startups sofrem.
Ferramentas de Monorepo
Turborepo
Cache inteligente, task paralela, remote cache. Simples de setup. Ideal pra Next.js apps e libraries.
Nx
Poderoso mas complexo. Dependency graph, affected commands, plugins. Melhor pra monorepos grandes.
pnpm workspaces
Básico mas funcional. Symlinks entre packages. Sem features avançadas. Suficiente pra monorepos simples.
Lerna (legado)
Veterano de monorepo. Meio abandonado. Turborepo e Nx são sucessores modernos.
Framework de Decisão
Checklist pra adotar Monorepo
- Projetos compartilham código significativo?
- Atomic changes cross-project são frequentes?
- Time trabalha em múltiplos projetos?
- Você vai usar Turborepo/Nx?
- CI/CD suporta builds seletivos?
- Repo não vai ficar gigante (< 50 packages)?
4+ sim: Monorepo faz sentido. 2-3: teste com tool simples. 0-1: multi-repo é mais direto.
Começando Pequeno
Não migre tudo pra monorepo de uma vez. Comece com packages internos. Depois adicione apps. Use Turborepo pra caching desde o início. Escale conforme necessidade.
Perguntas frequentes
Quando SIM usar Monorepo
Web, mobile, admin usando mesmas libs. Monorepo permite imports diretos. Mudança em lib atualiza todos apps simultaneamente. Mudar API e atualizar clientes em um PR. Sem monorepo são múltiplos PRs coordenados. Monorepo simplifica refactors grandes. Se mesmos devs tocam web, API, mobile, monorepo evita trocar de repo. Menos context switching, mais produtividade.
Quando NÃO usar Monorepo
Se web e API não compartilham nada, monorepo é overhead. Multi-repo com versionamento separado é mais simples. Time A só toca projeto X, time B só projeto Y. Sem overlap. Monorepo adiciona complexidade sem benefício. Sem tool como Nx, cada commit builda tudo. Lento demais. Se sua CI é simples, multi-repo é mais direto.