O Webpack e o Desenvolvedor Curioso: Vale a Pena Aprender a Configurar um Boilerplate do Zero, "na unha"?

Tempos atrás eu configurei um boilerplate do zero utilizando Webpack. Foi uma jornada de aprendizado interessante. Em breve trarei um artigo explicando o passo a passo dessa experiência. Por agora, quero apenas compartilhar algumas reflexões sobre como uma experiência assim pode agregar para nossa prática de desenvolvimento de software.

Algumas experiências do desenvolvedor iniciante fazem parecer contra-produtivo se empenhar em desenvolver um boilerplate do zero:

• Quando começamos a aprender frameworks e bibliotecas JavaScript, os cursos geralmente nos direcionam para boilerplates prontos, criados por ferramentas como CRA, Vite etc.
• Nos projetos em que já trabalhei como freelancer, estes boilerplates prontos deram conta do recado.
• A maioria dos projetos das empresas já existem quando os devs entram. Então, eles não precisam fazer a configuração do zero.

Tudo isso faz parecer perda de tempo aprender a configurar um boilerplate “na unha”, tomando decisões de customização para cada opção do arquivo de configurações do Webpack e para cada lib que interage com ele.

Apesar destes fatos, não é necessário um extremo exercício mental para entendermos que o conhecimento profundo sobre uma ferramenta que é o alicerce da maioria dos projetos de um ecossistema está longe de ser um desperdício de tempo. Se você trabalha no ecossistema JavaScript, deve saber que atualmente existem alternativas ao Webpack, que prometem uma performance melhor. Aqui eu não entrarei no mérito das vantagens e desvantagens dos empacotadores. O ponto é que o Webpack ainda é muito popular e muitos projetos em que daremos manutenção foram construidos com ele.

Ao criar um boilerplate eu não tive a intenção de aprender para sair por aí reproduzindo essa prática como uma prática recreativa, embora admita que me empolgou bastante🤣. A ideia foi ter UM boilerplate para usar quando necessário, com configurações que são básicas para a maioria dos projetos e que me desse liberadade arquitetural, quando fosse necessário aplicar determinado padrão de arquiterura a um projeto. Sim, liberdade, amigos. Eu sei que para quem desenvolve software tudo é posśivel, inclusive gambiarras. Então, também sei que dá para adaptar boilerplates criados por algumas ferramentas de uso comum para atender a uma arquitetura de projeto, mas, convenhamos, estaremos lutando contra uma configuração padrão realizada por essas ferramentas. E, no final das contas, não sabemos como outros devs, que posterioremente trabalharão no projeto, entenderão a adaptação que fizemos.

A fim de escolher a configuração para cada opção do arquivo de configurações do Webpack, eu tive de pesquisar sobre todas as possibilidades. O mesmo aconteceu ao configurar o Typescript, os linters etc. Mas confesso que a sensação de “abrir o capô”, proporcionada por toda essa pesquisa, recompensou a trabalheira.

A verdade é que para quem trabalha em um projeto com Webpack, este bundler é um ambiente de trabalho que muitas vezes a pessoa só conhece o escritório, embora existam outras dependências, incluindo um sótão e um porão nunca antes visitados. Você não sabe o que tem lá. Para além da sensação de segurança advinda de conhecer melhor o “local de trabalho”, conhecer as entranhas do Webpack traz facilidades para identificar problemas que surgem relacionados a transpilação de código, incompatibilidade com versões de libs etc. Quando surge um problema, você já tem pistas. Pelo menos já sabe em quais locais deve iniciar a busca. E, ao encontrar a causa, tem maior facilidade em resolver a situação.

Com base na experiência que tive, recomendo a todos que trabalham com JavaScript, mas que ainda não tiveram a oportunidade de configurar um boilerplate do zero, utilizando Webpack, que o façam logo que tiverem um tempinho. O objetivo não deve ser construir o boilerplate dos sonhos, abandonar o Vite para usar sua própria obra prima em todos os projetos. Até mesmo porque o meu está longe de ser um primor e sempre estou fazendo modificações nele. Além disso, toda decisão sobre ferramentas e padrões de arquitetura deve ser feita caso-a-caso, de acordo com os requisitos de cada projeto. O ponto a considerar é a visão que você ganhará com isso, o conhecimento sobre cada pequeno agente que integra o bonde e contribui para o resultado final, e como esse resultado seria diferente se cada biblioteca fosse configurada de maneira diversa.

E você? O que pensa a respeito? Compartilhe sua opinião sobre esse assunto. É confrontando ideias que expandimos nossos horizontes. A comunidade será grata por suas considerações. ;)