13 pontos por xguru 2024-06-02 | Ainda não há comentários. | Compartilhar no WhatsApp
  • No início do desenvolvimento, o tempo de build era de cerca de 30 segundos, o que era aceitável, mas, à medida que mais funcionalidades foram adicionadas, ele aumentou para 1 minuto e 10 segundos
  • Tempos de build longos tornam o processo de desenvolvimento mais lento, aumentam o tempo de onboarding de novos desenvolvedores e dificultam a concentração nas tarefas do dia a dia

Tentativa de melhoria por meio de um hackathon

  • Em janeiro, a equipe coletou dados, escreveu uma proposta de projeto para o hackathon, aprofundou o entendimento do sistema de build existente e buscou formas de fazer profiling
  • Todo o processo de build foi perfilado com OpenTelemetry e Jaeger
    • O profiling mostrou que a execução de Webpack/Rollup consumia a maior parte do tempo de build
    • Também foi descoberto que pequenas dependências estavam sendo buildadas uma a uma, o que criava muitas oportunidades para processamento em paralelo
    • No início, algumas tarefas mais pesadas estavam levando mais tempo do que o necessário, atrasando o restante do processo de build
  • Durante o hackathon, o foco foi reduzir o tempo de bundling com esbuild
    • O uso do esbuild como loader do Webpack/Rollup trouxe grande ganho de desempenho (no caso do Rollup, redução de 80%)
    • O uso do esbuild como bundler para substituir completamente Webpack/Rollup reduziu o tempo de bundling em 90%
  • Como resultado do projeto do hackathon, o tempo de build da extensão foi reduzido em mais de 70%, chegando a cerca de 15 segundos

Trabalho para aplicar em produção

  • Como o projeto do hackathon usava muitos paliativos, foi necessário substituí-los por uma solução real para uso em produção
    • Migrar totalmente do uso de Webpack e Rollup para esbuild
    • Consolidar o processo de build em um único local
    • Resolver problemas no processamento de assets gráficos
    • Adicionar novamente a verificação de tipos do TypeScript ao processo de build
    • Testar builds de produção e comparar tamanho e funcionalidade
    • Refletir alterações em dependências internas
    • Reproduzir outros aspectos do sistema de build anterior, como a etapa de build do Sentry
    • Adicionar tratamento para navegadores que não são Chrome, polyfills e exigências de build específicas de cada loja
  • O trabalho se concentrou na verificação de tipos e na otimização do tamanho do bundle

Adição de verificação de tipos ao esbuild

  • Como o tsc é lento, é difícil usá-lo junto com o processo de build rápido do esbuild
  • Foi usado o plugin da comunidade esbuild-plugin-typecheck para executar o tsc em worker threads e aproveitar compilação incremental
  • A equipe também implementou um plugin simples próprio de verificação de tipos, executando processos do CLI do tsc em paralelo para cada raiz de pacote
    • As mensagens de diagnóstico da compilação do tsc foram convertidas para o formato nativo do esbuild, melhorando a legibilidade
    • Com a flag tsc --listFilesOnly e o Metafile do esbuild, foi possível verificar automaticamente se todas as entradas de build estavam passando por verificação de tipos

Melhoria do tamanho do bundle de produção

  • O analisador de tamanho de bundle do esbuild foi usado para analisar o bundle de produção
    • Foi encontrado um problema em que os builds ESM e CJS da biblioteca de componentes de UI estavam sendo incluídos juntos no bundle
    • A correção de uma configuração incorreta em uma biblioteca interna reduziu o tamanho do bundle (3.3MB -> 2.1MB)
    • O efeito de redução de tamanho também foi confirmado em vários entrypoints

Impacto e conclusão

  • Na implementação em produção, o tempo de warm build foi reduzido em mais de 90%, chegando a cerca de 5 segundos
  • No modo watch, alterações em arquivos TypeScript podem ser recompiladas em menos de 1 segundo
  • Os desenvolvedores deram feedback de que a eficiência no trabalho melhorou muito com o novo sistema de build
  • Graças ao esforço da equipe de QA e de desenvolvedores volunteers, a transição para o novo sistema de build aconteceu sem problemas
  • Em uma pesquisa de satisfação com desenvolvedores, a insatisfação com o tempo de build caiu drasticamente de 97% para 5%
  • O esbuild é uma ferramenta excelente, e projetos de hackathon são ideais para esse tipo de trabalho

Ainda não há comentários.

Ainda não há comentários.