Migrando do Webpack 1 para o 4: Como fizemos aqui na iClinic

Neste post, vamos falar um pouco do nosso processo de reescrita de código para criação dos bundles de uma aplicação legada que trabalhamos dentro da iClinic. Vamos falar das motivações, planos e resultados que tivemos ao encarar este desafio nada fácil.

Photo by Markus Spiske on Unsplash

Motivação 💪

O que mais nos motivou a iniciar esse processo de migração foi eliminar algumas bibliotecas depreciadas e deixar a estrutura mais simples e rápida. Nosso processo de build era extremamente burocrático e difícil de entender, afinal, era um código legado de 5 anos.

Alguns dos itens que nos fizeram repensar:

• Código legado;
• Compass para funções utilitárias no SASS;
• Dependência do Ruby (por conta do Compass);
• Grunt para compilação do SASS;
• Webpack na versão 1;
• Tempo médio para rodar o build por completo: 8 minutos; (dependendo muito do processamento, mas já tivemos builds de até 15 minutos);

Tomamos como missão remover tudo isso, e unificar toda essa regra de trabalhar com arquivos Javascript, SCSS, imagens e até fontes para dentro do Webpack, sem precisar de mais nada para fazer todo o build.

Qual era o plano? 🤔

Criar tudo do absoluto 0. Não gostaríamos de fazer um refactoring, simplesmente pelo fato de não entender o que estava acontecendo no código atual.

Tendo isso em mente, decidimos ir trabalhando com pouco código e ir adicionando plugins e configurações no Webpack conforme a aplicação fosse pedindo. Assim, conseguiríamos remover muito código que não estava mais sendo usado, além de remover bastante lógica que no Webapack 4 já vem built-in.

Durante o processo 🏃

Encontramos muitos desafios e tivemos muito aprendizado!

É sempre muito importante ver como outras empresas resolveram problemas parecidos, então levar dúvidas e pedir sugestões para a comunidade foi uma parte muito importante.

Falando nisso, deixo aqui um agradecimento especial ao Matheus Silva que nos ajudou muito nesse processo de migração.

Ganhamos tempo? ⏰

Sim! Em ambiente de desenvolvimento após tudo pronto, ele finaliza entre 30~35 segundos, e a cada alteração nos arquivos ele faz o rebuild em ~1 segundo.
Em produção, pelo fato de utilizarmos uma série de otimizações no Webpack, o build finaliza entre 45~60 segundos.

Estrutura de pastas após finalização

Como ficou? 📈

Separamos por pastas e responsabilidades (css/js). Tudo relacionado a build ficou dentro da pasta webpack.

Alguns pontos importantes que é legal ressaltarmos:

• Como o webpack ficou responsável pelo CSS e Javascript, precisamos utilizar paralelismo para carregar 2 configs de webpack ao mesmo tempo, justamente para otimizar o processo. No caso, utilizamos paralell-webpack que é uma lib desenvolvida pelo Trivago.
• Pelo fato de termos muitos entry-points, foi essencial o uso do thread-loader .

Deu certo? ✅

Sim, com isso conseguimos otimizar muito nosso tempo de desenvolvimento pelo fato do build rodar bem mais rápido, sem contar que economizamos muito processamento de CPU. Pelo fato do build ter ficado mais rápido, consequentemente ganhamos tempo também no momento do deploy.

Como foi removida toda dependência do Ruby e Compass e deixado apenas para o Node com Webpack, tornou-se possível começarmos a pensar numa estratégia de CI/CD bem mais simples.

Com tudo isso entregue, abriram-se muitas portas e possibilidades para nosso time de desenvolvimento.

Lições aprendidas 💡

1. Faseamento: Trabalhamos por meses para entregar esta melhoria que acabou sendo publicada de uma só vez. Acabou dando certo, porém acho que se tivéssemos faseado e entregado pequenas partes os deploy’s teriam sido mais tranquilos e conseguiríamos entregar valor mais rápido para o usuário.
2. Webpack com CSS: Falando sobre a v4 do webpack, ele ainda, infelizmente não trabalha muito bem com arquivos CSS. Precisamos utilizar alguns plugins para corrigir alguns problemas, como webpack-fix-style-only-entries e webpack-watched-glob-entries-plugin. Temos planos de atualizar para Webpack 5 assim que estiver disponível, para remover estes plugins que não serão mais necessários. Acredito que se a responsabilidade de compilação do pré/pós processador CSS tivesse em outro domínio, como uma simples task no Gulp, teríamos ganhado tempo e o Webpack ficaria relativamente mais simples, pois não precisaríamos de paralelismo de configurações.
3. Nunca perca o controle sobre a atualização das dependências do seu projeto. É de suma importância que você utilize ferramentas como dependabot ou renovate, para começar uma cultura de atualizar as dependências assim que sairem novas versões.

Conclusão 🎯

Todo esse plano e forma que abordamos a atualização do Webpack deu muito certo, pois conseguimos remover muito código que de fato não estava sendo utilizado no processo.

Estamos com muitas vagas abertas, dê uma olhada aqui e vamos descomplicar a saúde do Brasil juntos!

Obrigado 💙