Bower ha muerto, larga vida a npm. Y a Yarn. Y a webpack.

Bower ya no es el administrador de dependencias preferido para los proyectos de frontend. Aunque el proyecto de código abierto sigue recibiendo mantenimiento, sus creadores decidieron dejar de desarrollarlo y recomiendan cómo migrar a otras soluciones, en particular, Yarn y webpack.

En esta publicación, explicamos por qué Bower era una gran herramienta, enumeramos seis razones por las que ya no es necesario y contamos cómo dar paso a tecnologías más nuevas y mejores.

¿Para qué servía Bower?

Bower es un administrador de paquetes, como npm, que administra frameworks, bibliotecas, recursos y utilidades; los instala y se asegura de que estén actualizados.

Tradicionalmente, muchos proyectos de desarrollo web combinaban npm y Bower. npm se usaba para administrar las dependencias de backend, mientras que Bower se usaba para las de frontend. De hecho, primero tenías que usar npm para instalar Bower.

La principal ventaja de Bower frente a npm era que tenía un grafo de dependencias plano. npm busca las dependencias de los paquetes y puede instalar automáticamente miles de dependencias y subdependencias, incluidas muchas copias duplicadas del mismo paquete. Como te imaginarás, esto no es ideal para los proyectos de frontend, ya que puede generar cargas muy pesadas.

Por otro lado, Bower dejaba la administración de las dependencias en manos del usuario. Por ejemplo, si un proyecto tenía muchas bibliotecas que dependían de jQuery, el usuario podía decidir qué versión de jQuery instalar y especificar esa versión como dependencia para las demás bibliotecas.

Aunque las ventajas de Bower eran convincentes, ahora las ofrecen otras herramientas, como npm, Yarn y webpack. Bower también tiene algunas desventajas importantes que debes conocer.

Seis razones para dejar de usar Bower y adoptar un nuevo flujo de trabajo

A continuación, presentamos las principales razones para dejar de usar Bower con las dependencias de frontend.

1. Sus creadores dejaron de desarrollar Bower

Después de un largo y acalorado debate en Github, los creadores de Bower decidieron que ya no aporta valor al stack actual de desarrollo web y que debería dejar de usarse. El proyecto de código abierto sigue recibiendo mantenimiento para ayudar a los usuarios actuales, pero esta es una razón de peso para no seguir usando la plataforma.

2. Bower ofrecía un grafo de dependencias plano, que ahora puedes obtener con npm y Yarn

npm 3 ofrece un grafo de dependencias plano, pero también permite usar varias versiones del mismo paquete cuando sea necesario (algo que Bower no puede hacer). Además, si usas Yarn, el comando yarn install --flat produce un efecto similar al de Bower (consulta la documentación de la CLI de Yarn).

3. Bower agrega complejidad y es redundante porque requiere npm

Bower necesitaba npm para funcionar. Por eso, una pregunta frecuente era: “¿por qué debería agregar otro administrador de paquetes si ya tengo npm?”

Para muchos, Bower ofrecía una separación útil entre los paquetes de backend y frontend. Sin embargo, hay formas de lograr esa misma separación en npm, por ejemplo, creando dos repositorios. En efecto, Bower parece ser un componente redundante para quienes ya usan npm.

4. Bower tiene un ecosistema de paquetes independiente

A los desarrolladores de módulos les gusta que npm esté presente en todas partes. Como todos usan npm, puedes publicar allí tu paquete más reciente y tener la certeza de que tus usuarios podrán acceder fácilmente a él. Sin embargo, hasta hace poco, los desarrolladores de paquetes de frontend tenían que publicarlos tanto en npm como en Bower, lo que resultaba menos práctico.

5. Bower dejaba la responsabilidad de administrar las dependencias en manos del usuario

Una de las mejores funciones de npm es que instala automáticamente todas las dependencias que necesitan los paquetes a los que hace referencia tu código. Aunque esto es muy práctico, también genera complejidad y puede llevar a un destino terrible conocido como infierno de dependencias.

Bower simplemente no ofrecía esta función, por lo que los usuarios tenían que definir laboriosamente qué paquete requería cada dependencia. Esto evitaba problemas con las dependencias, pero les generaba mucho trabajo manual a los usuarios.

Gracias a los avances recientes de npm y de tecnologías complementarias como webpack y Yarn, ahora es mucho más fácil trabajar con dependencias encadenadas.

6. Bower no admite distintas versiones del mismo paquete en una misma página

Es un caso poco frecuente, pero bastante común. En Bower no podías hacer referencia a la misma biblioteca desde dos paquetes distintos y usar dos versiones diferentes. npm 3 ofrece esta capacidad de forma predeterminada, junto con un grafo de dependencias plano.

¿Cómo se administran los paquetes hoy?

Mencionamos que herramientas más nuevas habían superado las ventajas de Bower. El stack moderno de dependencias, compuesto por npm/Yarn para administrar paquetes de Node y webpack para administrar recursos estáticos, dejó obsoleto a Bower:

• npm es el administrador de paquetes preferido, tanto para los paquetes de backend como para los de frontend.

• Yarn es una interfaz para npm que ofrece varias ventajas importantes: mayor velocidad al instalar dependencias, más capacidad para bloquear o fijar paquetes en una versión específica, mayor seguridad y un modo sin conexión. Desde el lanzamiento de npm 3, algunas de estas ventajas son menos notorias, por lo que vale la pena analizar si Yarn aporta valor a tu flujo de trabajo.

• webpack es un empaquetador de módulos o, en otras palabras, una herramienta de compilación. Ofrece cargadores y complementos que te permiten preparar las dependencias de archivos estáticos para tus proyectos web. Por ejemplo, webpack puede tomar varios archivos CSS, minificarlos e incluirlos en la compilación de tu proyecto. webpack cubre una carencia importante para quienes usan npm, ya que muchos de los recursos para crear una aplicación web no son componentes de Node.js. webpack puede incorporar, preparar e instalar todos esos otros elementos, mientras npm instala las bibliotecas de Node que usa la aplicación web.

Ya hay excelentes recursos para migrar de Bower a un stack más moderno y versátil, como el excelente artículo de Anrejs Abrickis y la publicación oficial de Adam Stankiewicz, creador de Bower.

Conclusión

La gran variedad de bibliotecas y frameworks de frontend disponibles hoy hace que usar un administrador de paquetes para gestionar las dependencias de frontend sea fundamental.

Bower desempeñó un papel importante en la mejora de la forma en que los desarrolladores de frontend administran sus dependencias: las ventajas que ofrecía sentaron las bases para funciones posteriores de npm y Yarn. Pero Bower ya no es la mejor opción. La llegada de Yarn y los cambios en npm 3 te permiten disfrutar de todas las ventajas de Bower sin complicaciones.

Migrar a npm o Yarn simplificará mucho tu proceso de desarrollo. Las herramientas actuales hacen que explorar la enorme variedad de componentes de frontend sea más fácil que nunca.