J’ai essayé Bower, l’outil de gestion des dépendances front-end

Pourquoi ?

Le management de librairies externes a toujours été un casse-tête pour les développements front en javascript. Combien de fois sommes-nous allés sur le site de jQuery afin de récupérer la dernière version, de la remplacer dans notre dossier “/libs” et de faire la modification dans notre balise <script> ?. Quand on a une vingtaine de dépendances, le travail commence à devenir relativement… agaçant ; sans parler des risques de non compatibilité et la gestion des rollback. On a beau parfois râler sur maven, on ne peut nier que celui-ci soulage beaucoup les développeurs java dans sa gestion des dépendances.

Node a apporté une première solution avec son npm (Node Packaged Modules), indispensable pour le développement d’applications en node.js. Celui-ci est malheureusement uniquement orienté “back” et le travail côté front reste toujours manuel.

Puis bower s’est présenté à moi.

Bower c’est quoi ?

Bower c’est donc un outil de management de librairies pour le web. Il s’installe le plus facilement du monde avec la commande : npm install -g bower

Il fonctionne en s’appuyant sur github pour télécharger les composants grâce à des tables de correspondances “name” : ”url” (par défaut : https://bower.herokuapp.com/packages mais il est tout à fait possible de la remplacer ou d’en rajouter).

Bower gère aussi les versions de projets grâce aux tags. Ainsi, pour installer jquery, la commande code>bower install jquery#2.0.0 ira chercher le tag 2.0.0 de l’url github correspondant au nom jquery dans la table d’assocations. Par défaut c’est donc à l’url git://github.com/components/jquery.git (et non sur le repo officiel) qu’il ira chercher jquery. Pourquoi pas l’url officielle ? Car bower se contente simplement de rapatrier TOUT le repo en local, et le repo https://github.com/jquery/jquery contient beaucoup de choses inutiles pour nous qui voulons simplement utiliser le jquery.js.

Si le projet n’est pas présent dans la table d’associations, pas de problème, on peut directement appeler l’url github pour installer le composant (bower install git@github.com:components/jquery.git#2.0.0 marche aussi très bien).

A noter que si on ne définit pas de version (bower install jquery), bower ira chercher par défaut la dernière version compatible disponible. Je dis bien dernière version compatible car bower gère aussi les conflits de versions grâce au fichier component.json des composants. Par exemple, nous voulons installer jquery et backbone et Marionette. Le fichier component.json de Marionette stipule qu’il faut utiliser une version 1.8.x de jquery. Bower, voyant cela, ira, si on ne lui spécifie pas de version de jquery, chercher la version 1.8.3.

C’est plutôt utile pour éviter de mauvaises surprises. Encore faut-il que ces fichiers soient à jour et présents dans tous les projets github, ce qui est aujourd’hui loin d’être le cas.

S’appuyer sur github fait la force et la faiblesse de bower. Bower possède, grâce à cela, une base énorme de composants, se reposant sur un système générique et indépendant. Et chacun peut facilement rajouter son projet au registry de bower. Cependant, comme nous allons le voir, les projets ne sont pas tous aussi “bower compatible” et l’hétérogénéité des structures des projets freine parfois le côté automatique des imports.

Mise en pratique

Pour se faire une idée plus claire de bower, je vous propose de l’intégrer dans un de mes projets présents sur github : mon Marionette boilerplate qui me sert de support à de nouveaux projets sur ce framework. Un serveur node.js est présent pour lancer l’application.

Ce projet utilise les librairies JS suivantes (en mai 2013) :

• backbone 1.0.0
• marionette 1.0.2 (avec json2, babysitter, et wreqr)
• underscore 1.4.4
• jQuery 2.0.0
• requirejs 2.1.5
• with text plugin 2.0.5+
• mustache 0.7.2
• hogan 3.0.0
• Twitter Boostrap 2.3.1
• less 1.3.3

J’utilise requireJS pour la gestion du chargement des fichiers JS. Mes fichiers JS sont aujourd’hui importés manuellement dans le dossier /public/js/libs

Je commence d’abord par créer le ficher bower.json dans le dossier “public”. Je le place ici et non à la racine du projet car bower n’est destiné qu’à la partie front de l’application.

Le fichier bower.json va me permettre de définir tous les composants que je veux importer. Voici la structure du fichier, c’est très simple :

bower.json

{
 "name": "Marionette-Boilerplate",
  "version": "0.0.1",
 "dependencies": {
   "jquery": "2.0.0",
    "backbone": "1.0.0",
    "marionette": "1.0.2",
    "underscore": "1.4.4",
    "requirejs": "2.1.5",
    "requirejs-text": "2.0.6",
    "mustache": "latest",
    "hogan": "latest",
    "bootstrap": "latest",
    "less.js": "latest"
  }
}

Une simple commande bower install lira le fichier et installera les composants en local. 

Le problème est que, par défaut, bower crée un dossier components pour importer les librairies javascript. Or, je voudrais pouvoir les mettre dans mon dossier libs déjà existant. Pour cela il faut créer un fichier de configuration .bowerrc au même niveau que mon bower.json comme-ceci :

.bowerrc

{
  "directory": "js/libs",
  "json": "bower.json"
}

C’est aussi ici que vous pouvez définir de nouvelles tables de dépendances pour vos projets. bower install, les packages s’installent maintenant dans le bon dossier/

Bower me jette par contre un warning comme quoi il pourrait y avoir des problèmes de compatibilité. En effet, j’installe une version 2.0.0 de Jquery alors que le fichier component.json de bootstrap indique une compatiblité avec jquery seulement dans ses version 1.8.x. Bower m’a tout de même importé la version 2.0.0 et c’est très bien comme ça !

une fois l’installation terminée, je lance un bower list pour voir mes packages installés :

Marionette-Boilerplate
├── backbone#1.0.0
├── backbone.babysitter#0.0.6
├── backbone.wreqr#0.2.0
├─┬ bootstrap#2.3.2
│ └── jquery#2.0.0
├── hogan#78d244777d120c0e365644a21e45a81407c48bc2
├── jquery#2.0.0
├── json2#ff55d8d4513b149e2511aee01c3a61d372837d1f
├── less.js#1.4.0-b4
├─┬ marionette#1.0.2
│ ├── jquery#2.0.0
│ └── backbone#1.0.0
├── mustache#0.7.2
├── requirejs#2.1.5 (2.1.6 now available)
├── requirejs-text#2.0.6
└── underscore#1.4.4

On peut voir que bower me prévient qu’il existe une version de requirejs plus récente. Bower a balayé tous les repos github des projets en cherchant des tags plus récents. C’est très pratique pour voir d’un coup d’œil si nous avons les dernières versions des projets. Je mets donc mes projets à jour.

 On peut voir un numéro de version plutôt affreux de la part de hogan (et json2). En effet, Hogan n’a pas de tag sur son repo github (https://github.com/twitter/hogan.js!

Maintenant il ne reste plus qu’à modifier mon fichier index.html et reconfigurer requirejs comme ceci :

index.html

<!DOCTYPE html>
<html lang="en">
<head>
    <title>Marionette Boilerplate</title>
    ...
    <script src="js/libs/less.js/dist/less-1.3.3.min.js" type="text/javascript"></script>
    <script data-main="js/config.js" src="js/libs/requirejs/require.js"></script>
</head>
...
</html>

config.js

require.config({
 baseUrl: 'js',
 paths: {
  jquery: 'libs/jquery/jquery',
  underscore: 'libs/underscore/underscore',
  backbone: 'libs/backbone/backbone',
  babysitter: 'libs/backbone.babysitter/lib/backbone.babysitter',
  wreqr: 'libs/backbone.wreqr/lib/backbone.wreqr',
  marionette: 'libs/marionette/lib/backbone.marionette',
  json2: 'libs/json2/json2',
  hogan: 'libs/hogan/web/1.0.0/hogan',
  mustache: 'libs/mustache/mustache',
  text: 'libs/requirejs-text/text',
  bootstrap: 'libs/bootstrap/docs/assets/js/bootstrap'
 },
 ...
});

Voilà, ça marche.

Je ne suis tout de même pas totalement satisfait. Hogan s’intègre très mal à bower, je suis obligé de spécifier la version dans mon import requirejs. Je devrai donc manuellement le changer lors d’une future mise à jour. De plus, les urls sont, comme je le craignais, hétérogènes. Si pour jquery, underscore ou backbone, la logique est la même, pour bootstrap je dois utiliser un chemin plus que douteux. Pour finir, tous mes composants ne possèdent pas de component.json. Je ne suis donc pas totalement sûr de la compatibilité entre mes versions. Tout ceci est sans doute imputable à la relative jeunesse du projet.

Pour conclure

Bower a eu la bonne idée de se reposer sur github pour sa gestion des composants, ce qui rend le catalogue immensément riche dès à présent. Sa simplicité et sa non-intrusion dans les autres briques du projet est aussi très appréciable. Couplé à grunt, bower devient un allié très puissant. Yeoman l’intègre d’ailleurs par défaut dans son workflow de création d’applications web.

Tout n’est pas rose cependant. Les projets sur github ont des architectures différentes et prennent plus ou moins (ou pas du tout) en compte bower. Ceci entraine une certaine frustration dans l’import des librairies. La solution serait qu’un compte github soit entièrement dédié aux imports des composants comme c’est déjà le cas avec le compte "Components" (https://github.com/components) qui ne possède pour l’instant que 33 repos. Bower pourrait aussi devenir plus strict dans l’ajout de librairies à son catalogue, comme par exemple obliger la présence du fichier component.json ou le respect d’une certaine architecture. Entre la qualité et la quantité, il faut souvent choisir…

Le fait que bower importe tous les fichiers des repos est aussi parfois frustrant dans la mesure où on n’utilise souvent qu’un fichier dans tout le repository.

Les choses devraient tout de même s’améliorer avec l’adoption massive de cette solution (si adoption il y a). Bower reste un outil pratique et je vais continuer à l’utiliser pour mes prochains projets front !