Selecionar e configurar ferramentas de build com base nas práticas recomendadas.
Hoje, o web.dev está lançando uma nova iniciativa chamada tooling.report. É um site que oferece aos desenvolvedores Web uma visão geral dos recursos compatíveis com várias ferramentas de build conhecidas. Criamos este site para ajudar você a escolher a ferramenta de build certa para seu próximo projeto, decidir se vale a pena migrar de uma ferramenta para outra ou descobrir como incorporar práticas recomendadas à configuração de ferramentas e à base de código. As ferramentas têm diferentes áreas de foco e atendem a um conjunto diferente de necessidades, o que significa que selecionar e configurar ferramentas envolve compensações. Com o tooling.report, nosso objetivo é explicar essas compensações e documentar como seguir as práticas recomendadas com qualquer ferramenta de build.
Parece emocionante? Acesse tooling.report para começar a explorar ou continue lendo para saber mais sobre por que e como desenvolvemos este site.
Ferramentas de build muitas vezes atrapalham
Na GoogleChromeLabs, criamos apps da Web, como Squoosh e Proxx, além de sites como o da Chrome Dev Summit 2019. Como em qualquer projeto de desenvolvimento da Web, geralmente começamos discutindo a infraestrutura do projeto, como o ambiente de hospedagem, os frameworks e a configuração da ferramenta de build. Essa infraestrutura é atualizada à medida que o projeto avança: novos plug-ins são adicionados para acomodar frameworks ou técnicas que adotamos, ou a maneira como escrevemos códigos é alterada para que nossas ferramentas de build entendam melhor o que estamos tentando alcançar. Ao longo desse processo, muitas vezes descobrimos que as ferramentas que selecionamos acabam atrapalhando.
O foco da nossa equipe é fornecer aos usuários a melhor experiência da Web, o que geralmente resulta em ajustes na forma como nossos recursos de front-end são montados e entregues. Por exemplo, se um script de linha de execução principal e um script de worker da Web tiverem dependências compartilhadas, faremos o download das dependências uma vez em vez de agrupá-las duas vezes para cada script. Algumas ferramentas oferecem suporte imediato a isso, outras precisam de um esforço de personalização significativo para mudar os comportamentos padrão e, para outras, isso é totalmente impossível.
Essa experiência nos levou a investigar o que diferentes ferramentas de build podem ou não fazer. Nossa esperança era criar uma lista de verificação de recursos para que, na próxima vez que começarmos um novo projeto, possamos avaliar e escolher qual ferramenta é mais adequada para nosso projeto.
Nossa abordagem
Como podemos avaliar e comparar diferentes ferramentas de build em um só lugar? Para abordar isso, escrevemos casos de teste.
Nossa equipe discutiu e elaborou critérios de teste que acreditamos representar as práticas recomendadas para desenvolvimento da Web. Focamos especificamente em como oferecer experiências do usuário rápidas, responsivas e suaves, excluindo intencionalmente testes relacionados à experiência do desenvolvedor para evitar medir dois resultados incomparáveis.
Depois que a lista de testes foi criada, escrevemos um script de build para cada ferramenta com o objetivo de verificar se ela pode atender aos critérios de sucesso do teste. Como um conjunto inicial, decidimos investigar o webpack v4, o Rollup v2 e o Parcel v2. Também testamos Browserify + Gulp, já que muitos projetos ainda usam essa configuração. Para que um teste seja aprovado, somente recursos da ferramenta documentados publicamente ou de um plug-in podem ser usados. Após a criação do conjunto inicial de testes, trabalhamos com os autores da ferramenta de build para garantir que usamos as ferramentas corretamente e as representás de maneira justa.
Usamos apenas ${tool_name}. Devo me importar mesmo assim?
Em muitas equipes, há pessoas dedicadas à manutenção da infraestrutura de build, e outros membros talvez nunca escolham quando se trata de criar ferramentas. Esperamos que o site ainda seja útil para você, como uma forma de definir expectativas para as ferramentas que você usa. Incluímos uma explicação sobre a importância dele para cada teste, além de recursos adicionais. Se você quiser adotar uma prática recomendada com a ferramenta da sua escolha, a configuração de teste no nosso repositório contém os arquivos de configuração necessários.
Posso contribuir com o site?
Se você achar que um determinado recurso está ausente no momento, proponha-o em um problema do GitHub para iniciar a discussão. Nosso objetivo é encapsular casos de uso reais, e qualquer teste adicional que avalie melhor esses resultados é bem-vindo.
Se você quiser programar testes para ferramentas que não incluímos no conjunto inicial, esse recurso é bem-vindo! Consulte CONTRIBUTING.md para mais informações.