La gestión de dependencias puede ser complicada. Cuando me uní a dojo4 hace unas semanas, fue genial clonar un repositorio de proyecto de ruby on rails, poder hacer un bundle install y luego poder ejecutar la aplicación con rails s. Para aquellos de ustedes que no estén familiarizados con la gestión de dependencias de ruby on rails, las gemas que se necesitan para ejecutar la aplicación se enumeran en un archivo llamado Gemfile. La aplicación bundle lee este archivo gemfile y descarga e instala cualquier gema que aún no esté en su computadora. No solo esto hace que sea fácil poner en marcha la aplicación correctamente de manera rápida y sin mucho esfuerzo de configuración, sino que también facilita la actualización de esas gemas dependientes cuando se lanza una nueva versión. Ejecutar bundle update o actualizar el archivo gemfile y volver a ejecutar bundle install hace que este sea un proceso fácil que garantiza que todos los demás usuarios de la aplicación también usarán la nueva versión (siempre que compartamos los cambios a través del control de origen). Esta es una excelente manera de trabajar para el lado del servidor, pero ¿qué pasa con el lado del cliente?

A medida que las aplicaciones del cliente se vuelven más complicadas, a menudo necesitamos la ayuda de bibliotecas y marcos en el cliente también. En dojo4, actualmente descargamos los archivos que necesitamos y los dejamos manualmente en el control de origen y los confirmamos. Los archivos están bajo control de origen, por lo que al menos todos obtendrán esos archivos y podremos revertir una actualización de versión, pero es un poco desordenado. Para actualizar los archivos de la biblioteca, tenemos que repetir el proceso manual. En el lado del servidor, también es realmente agradable que las tareas de gestión de dependencias estén menos estrechamente acopladas al código de la aplicación para que actualizar y volver a versiones anteriores sea más fácil. Desafortunadamente, no había una buena manera de gestionar las dependencias para el front end. Hasta hace poco.

En septiembre del año pasado, Twitter lanzó Bower, que ofrece "una solución genérica y sin opiniones al problema de la gestión de paquetes del front-end". Bower proporciona las mismas capacidades para la aplicación del front-end que bundle hace para el back end: una lista central de dependencias en un archivo, comandos de instalación y actualización fáciles, y algo de separación del código de la aplicación y los commits. Mientras investigaba cómo podríamos aprovechar esto en nuestra aplicación estándar de ruby on rails, los creadores de Bower me remitieron a la gema bower-rails, que integra bower en la estructura de directorios de ruby on rails y agrega algunos comandos rake para ejecutar comandos de bower. Ahora, en lugar de confirmar manualmente los archivos de la biblioteca en el repositorio de la aplicación, un desarrollador puede hacer rake bower:install [nombre del paquete] y la última versión de ese paquete se instalará en el pipeline de activos y se agregará a la lista de paquetes requeridos. Un nuevo desarrollador puede luego descargar el código de la aplicación y, después de ejecutar bundle install, puede ejecutar rake bower:install y todas las dependencias del front-end se instalarán en el directorio adecuado en el pipeline de activos de ruby on rails para su uso inmediato.

Personalmente, me gusta mucho este enfoque y espero que podamos convertir las bibliotecas del front-end que se agregan manualmente al enfoque de bower. Todavía estamos discutiendo internamente los beneficios y desventajas y tomaremos una decisión pronto. ¿Qué piensas? ¿Cómo manejas las dependencias del front-end en un equipo distribuido?