Projeto Ledger Live Monorepo: Parte 2 - As ferramentas (faça brilhar) | Razão

Projeto Ledger Live Monorepo: Parte 2 – As ferramentas (faça brilhar) | Razão

Nó Fonte: 2985172

Segunda entrada da série de postagens do blog “Ledger Live Monorepo Project”, onde um desenvolvedor do Ledger nos conta a história da enorme migração da base de código do Ledger Live para um repositório mono. Se você perdeu a parte 1, confira aqui:

Depois de estabelecer que uma arquitetura monorepo era uma solução viável, começamos a analisar as ferramentas disponíveis para implementar nosso plano.

Lidando com vários projetos

Na equipe Ledger Live navegamos no ecossistema JavaScript e, felizmente para nós, já conhecíamos várias maneiras de lidar com vários projetos com nosso gerenciador de pacotes. Algumas dessas soluções possíveis incluem:

  • NPM (tem suporte para espaços de trabalho, mas alternativas melhores),
  • Fio 1 (tornando-se alternativas muito antigas, melhores e mais eficientes),
  • Fio ≥ 2 (ideia interessante, mas plug and play não é bem suportado em todos os lugares, especialmente com React Native),
  • PNPM (links simbólicos, criados com os espaços de trabalho em mente, com eficiência de disco).

Depois de olhar para tudo isso, decidimos ir com PNPM para:

  • a eficiência do disco (ele usa um virtual loja e links simbólicos, então os pacotes são baixados apenas uma vez e depois vinculados simbolicamente ao seu node_modules da loja virtual),
  • a velocidade (como os pacotes são armazenados em cache, as instalações subsequentes são muito mais rápidas),
  • suporte integrado para espaços de trabalho/arquitetura monorepo (aliases, orquestração, etc.).

No papel PNPM é uma jóia absoluta, mas os links simbólicos eram um pouco estranhos para serem configurados corretamente (novamente, especialmente com React Native).

Ok, então nossa escolha foi feita, iríamos com PNPM.

Orquestração de roteiro

Apesar de PNPM adiciona cada vez mais orquestração aos seus recursos, ainda não cobre tudo o que queríamos fazer, como:

  • construções sequenciais,
  • cache.

Para estes, encontramos dois candidatos interessantes que precisávamos dar uma olhada:

  • NX (pela equipe angular),
  • turborepo (que acabamos de anunciar a v1.0.0 quando começamos a trabalhar nela, e agora trabalhamos com a equipe Vercel).

Fizemos uma prova de conceito em ambos.

NX tinha muito mais recursos, geradores, automação, ótimos gráficos de dependência etc… mas acrescentava muita sobrecarga e, como é bastante opinativo, teríamos que seguir suas convenções.

turborepo por outro lado, é bastante básico em termos de recursos. No entanto, é uma solução plug and play conveniente que poderíamos mudar muito rapidamente se necessário.

Apesar de turborepo tinha menos recursos do que NX, ele fez as duas coisas que procurávamos:

  • Orquestração de builds respeitando a árvore de dependências (e builds simultâneos),
  • Cache (as compilações são armazenadas em cache e 'repetidas' se o código não tiver sido alterado).

Isso, mais a facilidade de entrada / saída, nos fez escolher o novo garoto do quarteirão, TurboRepo.

Versão

Também analisamos várias soluções, mas finalmente decidimos usar https://github.com/changesets/changesets pois era uma ferramenta recomendada pelo TurboRepo, e depois de ler um pouco a documentação, parecia atender às nossas necessidades.

Os desenvolvedores precisariam ser um pouco mais rigorosos em seu fluxo de desenvolvimento e fornecer changesets (arquivo descrevendo qual biblioteca seu código muda, a gravidade seguindo o sempre convenção e uma descrição da mudança). Esses changesets são então usados ​​para alterar automaticamente a versão dos pacotes respeitando as severidades fornecidas, bem como automatizar a geração de registros de alterações. Além disso, as ferramentas permitem pre release modo, o 🍒 no 🍰.

Qual é o próximo ?

Depois de decidir sobre as ferramentas, era hora de começar a trabalhar. No próximo artigo do blog falaremos sobre o sistema de build e todo o dev-ops/automação/integração contínua no contexto de um repositório mono.


Valentín DE ALMEIDA
Experiência do desenvolvedor e tecnologia central – Ledger Live

Carimbo de hora:

Mais de Ledger