Bower morreu, vida longa ao npm. E ao Yarn. E ao webpack.

Bower deixou de ser o gerenciador de dependências preferido para projetos front-end. Embora o projeto de código aberto ainda seja mantido, seus criadores decidiram descontinuá-lo e recomendam como migrar para outras soluções — especificamente, Yarn e webpack.

Neste post, explicamos por que Bower já foi uma ótima opção, apresentamos seis motivos pelos quais ele não é mais necessário e mostramos como adotar tecnologias mais novas e melhores.

Para que Bower servia?

Bower é um gerenciador de pacotes, como o npm. Ele gerencia frameworks, bibliotecas, recursos e utilitários, instala esses itens e garante que estejam atualizados.

Tradicionalmente, muitos projetos de desenvolvimento web combinavam npm e Bower. O npm era usado para gerenciar dependências de back-end, enquanto o Bower cuidava das dependências de front-end. Na verdade, era preciso usar o npm para instalar o Bower.

A principal vantagem do Bower em relação ao npm era o grafo de dependências plano. O npm rastreia as dependências dos pacotes e pode instalar milhares de dependências e subdependências automaticamente, incluindo várias cópias duplicadas do mesmo pacote. Como você pode imaginar, isso não é ideal para projetos front-end, pois pode gerar pacotes muito pesados.

Por outro lado, o Bower deixava o gerenciamento das dependências a cargo do usuário. Por exemplo, se um projeto tivesse várias bibliotecas que dependessem do jQuery, o usuário poderia escolher qual versão instalar e especificar essa versão como dependência das outras bibliotecas.

Embora as vantagens do Bower fossem convincentes, outras ferramentas — como npm, Yarn e webpack — já oferecem os mesmos recursos. Além disso, o Bower tem algumas desvantagens importantes que você deve conhecer.

Seis motivos para parar de usar Bower e adotar um novo fluxo de trabalho

Confira os principais motivos para deixar de usar Bower nas dependências de front-end.

1. Os criadores do Bower descontinuaram a ferramenta

Depois de um longo e acalorado debate no GitHub, os criadores do Bower concluíram que ele não agrega valor à pilha atual de desenvolvimento web e deveria ser descontinuado. O projeto de código aberto continua sendo mantido para atender aos usuários existentes, mas esse é um dos principais motivos para não continuar usando a plataforma.

2. O Bower oferecia um grafo de dependências plano, que agora você pode obter com npm e Yarn

O npm 3 oferece um grafo de dependências plano, mas também permite usar várias versões do mesmo pacote quando necessário — algo que o Bower não consegue fazer. Para quem usa Yarn, o comando yarn install --flat tem um efeito semelhante ao do Bower (consulte a documentação da CLI do Yarn).

3. Bower adiciona complexidade e é redundante, pois depende do npm

O Bower precisava do npm para funcionar. Por isso, uma pergunta frequente era: “por que adicionar outro gerenciador de pacotes se já tenho o npm?”

Para muita gente, o Bower oferecia uma separação útil entre pacotes de back-end e front-end. Mas é possível fazer essa mesma separação no npm, por exemplo, criando dois repositórios. De fato, para quem já usa npm, o Bower parece ser um componente redundante.

4. Bower tem um ecossistema de pacotes separado

Desenvolvedores de módulos gostam do fato de o npm ser onipresente. Como todo mundo usa npm, você pode publicar seu pacote mais recente lá e ter a certeza de que seus usuários terão acesso fácil a ele. Até pouco tempo atrás, porém, quem desenvolvia pacotes de front-end precisava publicá-los tanto no npm quanto no Bower, o que era menos prático.

5. Bower deixava o gerenciamento de dependências a cargo do usuário

Um dos melhores recursos do npm é instalar automaticamente todas as dependências exigidas pelos pacotes referenciados no seu código. Embora isso seja muito prático, também aumenta a complexidade e pode levar a um destino terrível conhecido como inferno das dependências.

O Bower simplesmente não oferecia esse recurso: cabia aos usuários definir, manualmente e com muito trabalho, quais dependências cada pacote exigia. Isso evitava problemas com dependências, mas gerava muito trabalho manual.

Com os avanços recentes no npm e em tecnologias complementares como webpack e Yarn, ficou muito mais fácil lidar com dependências encadeadas.

6. Bower não oferece suporte a diferentes versões do mesmo pacote na mesma página

É um caso específico, mas bastante comum. No Bower, não era possível referenciar a mesma biblioteca por meio de dois pacotes diferentes usando versões distintas. O npm 3 oferece esse recurso por padrão, além de um grafo de dependências plano.

Como os pacotes são gerenciados hoje?

Como vimos, ferramentas mais novas substituíram as vantagens do Bower. A pilha moderna de gerenciamento de dependências — com npm/Yarn para gerenciar pacotes Node e webpack para gerenciar recursos estáticos — tornou o Bower redundante:

• npm é o gerenciador de pacotes preferido para pacotes de back-end e front-end.

• Yarn é uma interface para o npm que oferece várias vantagens importantes: instalação de dependências mais rápida, mais confiabilidade para travar ou fixar pacotes em uma versão específica, segurança aprimorada e modo offline. Desde o lançamento do npm 3, algumas dessas vantagens são menos perceptíveis. Por isso, vale analisar com atenção se o Yarn agrega valor ao seu fluxo de trabalho.

• webpack é um empacotador de módulos — ou, em outras palavras, uma ferramenta de build. Ele oferece loaders e plugins que permitem preparar as dependências de arquivos estáticos dos seus projetos web. Por exemplo, o webpack pode reunir vários arquivos CSS, minificá-los e incluí-los no build do seu projeto. O webpack preenche uma lacuna importante para quem usa npm, pois muitos dos recursos usados para criar um app web não são componentes do Node.js. O webpack pode buscar, preparar e instalar todos esses outros elementos, enquanto o npm instala as bibliotecas Node usadas pelo app web.

Já existem ótimos materiais sobre como migrar do Bower para uma pilha mais moderna e versátil, incluindo o excelente artigo de Anrejs Abrickis e o post oficial do criador do Bower, Adam Stankiewicz.

Conclusão

Com a infinidade de bibliotecas e frameworks front-end disponíveis hoje, usar um gerenciador de pacotes para administrar as dependências de front-end é fundamental.

O Bower teve um papel importante na evolução do gerenciamento de dependências para desenvolvedores front-end. As vantagens que oferecia abriram caminho para recursos que vieram depois no npm e no Yarn. Mas o Bower já não é a melhor opção. Com a chegada do Yarn e as mudanças no npm 3, você tem todos os benefícios do Bower sem complicações.

Migrar para npm ou Yarn vai simplificar muito seu processo de desenvolvimento. As ferramentas atuais tornam mais fácil do que nunca navegar pela enorme variedade de componentes front-end.