La gestion des dépendances peut être délicate. Lorsque j'ai rejoint dojo4 il y a quelques semaines, c'était génial de cloner un dépôt de projet ruby on rails, de pouvoir faire un bundle install et ensuite de pouvoir exécuter l'application avec rails s. Pour ceux d'entre vous qui ne sont pas familiers avec la gestion des dépendances de ruby on rails, les gemmes nécessaires pour exécuter l'application sont listées dans un fichier nommé Gemfile. L'application bundle lit ce gemfile et télécharge et installe les gemmes qui ne sont pas encore sur votre ordinateur. Non seulement cela facilite la mise en place rapide et sans effort de l'application, mais cela facilite également la mise à jour de ces gemmes dépendantes lorsqu'une nouvelle version est publiée. L'exécution de bundle update ou la mise à jour du gemfile et l'exécution de bundle install à nouveau rendent ce processus facile et garantissent que chaque autre utilisateur de l'application utilisera également la nouvelle version (à condition que nous partagions les modifications via le contrôle de source). C'est un excellent flux de travail pour le côté serveur, mais qu'en est-il du côté client ?

À mesure que les applications client deviennent plus compliquées, nous avons fréquemment besoin de l'aide de bibliothèques et de frameworks côté client également. Chez dojo4, nous téléchargeons actuellement les fichiers dont nous avons besoin et les déposons manuellement dans le contrôle de source et les validons. Les fichiers sont sous contrôle de source, donc au moins tout le monde obtiendra ces fichiers et nous pourrons revenir à une mise à niveau de version, mais c'est un peu désordonné. Pour mettre à jour les fichiers de la bibliothèque, nous devons répéter le processus manuel. Du côté serveur, il est également très agréable que les tâches de gestion des dépendances soient moins étroitement couplées au code de l'application afin que la mise à jour et le retour en arrière des versions soient plus faciles. Malheureusement, il n'y avait pas de bon moyen de gérer les dépendances pour le frontend. Jusqu'à récemment.

En septembre de l'année dernière, Twitter a publié Bower, qui offre « une solution générique et sans opinion à la gestion des packages frontaux ». Bower fournit les mêmes capacités pour l'application frontale que bundle pour le backend : une liste centrale des dépendances dans un fichier, des commandes d'installation et de mise à jour faciles, et une certaine séparation des commits et du code de l'application. En recherchant comment nous pourrions tirer parti de cela dans notre application ruby on rails standard, les créateurs de Bower m'ont orienté vers le gemme bower-rails, qui intègre bower dans la structure de répertoires ruby on rails et ajoute certaines commandes rake pour exécuter les commandes bower. Désormais, au lieu de valider manuellement les fichiers de bibliothèque dans le dépôt de l'application, un développeur peut faire rake bower:install [nom du package] et la dernière version de ce package sera installée dans le pipeline d'actifs et sera ajoutée à la liste des packages requis. Un nouveau développeur peut ensuite télécharger le code de l'application et, après avoir exécuté bundle install, peut exécuter rake bower:install et toutes les dépendances frontales seront installées dans le répertoire approprié dans le pipeline d'actifs ruby on rails pour une utilisation immédiate.

Personnellement, j'aime beaucoup cette approche et j'espère que nous pourrons convertir les bibliothèques frontales qui sont ajoutées manuellement à l'approche bower. Nous discutons toujours des avantages et des inconvénients en interne et prendrons bientôt une décision. Qu'en pensez-vous ? Comment gérez-vous les dépendances frontales dans une équipe distribuée ?