Skip to content
Latchkey

O Que É um Build de Monorepo? Construindo Muitos Pacotes de Frontend Juntos

Um build de monorepo compila muitos pacotes de frontend relacionados a partir de um repositório, idealmente reconstruindo apenas os pacotes afetados por uma mudança.

Um monorepo de frontend guarda muitos pacotes, como aplicações, uma biblioteca de componentes e utilitários compartilhados, em um repositório. Construir todos eles a cada mudança seria um desperdício. Uma ferramenta de build de monorepo modela as dependências entre pacotes e executa apenas o trabalho que uma mudança realmente exige. Essa seletividade é o que mantém o CI de monorepo rápido conforme o repositório cresce.

O task graph de pacotes

A ferramenta de build lê cada pacote e como eles dependem uns dos outros, formando um task graph. Uma mudança em um pacote compartilhado o marca, junto com seus dependentes, para reconstrução, enquanto pacotes não afetados são pulados.

Builds apenas do afetado

Comparando com um commit base, a ferramenta determina quais pacotes mudaram e constrói apenas esses mais seus dependentes. Em um repositório grande, isso transforma um rebuild completo em um pequeno para a maioria dos pull requests.

Fazendo cache dos resultados de tasks

  • Cada saída de task é armazenada em cache por um hash de suas entradas.
  • Uma task inalterada restaura sua saída em vez de reexecutar.
  • Um remote cache compartilha resultados entre máquinas e execuções de CI.

Ferramentas comuns

Ferramentas como Turborepo, Nx e Bazel fornecem task graphs e cache para monorepos. Elas diferem em escopo e configuração, mas as ideias centrais de detecção do afetado e saídas de tasks em cache são compartilhadas.

Builds de monorepo em CI/CD

O pipeline calcula os pacotes afetados, executa apenas suas tasks de build e teste, e restaura saídas em cache para o restante. Um remote cache compartilhado entre execuções de CI é o que faz isso escalar; sem ele, cada runner reconstrói tudo. Runners gerenciados (como o Latchkey) mantêm esse remote cache aquecido para que os pipelines de monorepo permaneçam rápidos.

Principais conclusões

  • Um build de monorepo usa um task graph para reconstruir apenas os pacotes afetados.
  • Saídas de tasks com hash e em cache permitem restaurar trabalho inalterado em vez de reexecutá-lo.
  • Um remote cache aquecido e compartilhado entre execuções de CI é o que mantém os pipelines de monorepo rápidos.

Guias relacionados