Dépendances clients : NPM vs Bower

Récemment, je suis arrivé sur un projet en cours de finalisation, et après quelques heures à l’explorer, je me suis rendu compte d’une chose : les dépendances javascript étaient enregistrées dans le dépôt.

Rien de bien grave me direz-vous, mais si on commence à garder toutes les dépendances PHP, javascript ou d’autres langages dans les dépôts, on va se retrouver avec quelques légères problématiques :

  • Le dépôt est encombré d’un nombre important de fichiers que nous ne maintenons pas. Ca prend un peu de place et surtout ça n’aide pas à s’y retrouver dans ce qu’on a pour mission de maintenir.
  • La mise à jour des dépendances passe par des commit très sales et compliqués
  • Certains peuvent être tentés de modifier une dépendance externe rendant assez problématique leur mise à jour future.

La solution : utiliser un système de gestion de dépendance, et ne surtout pas versionner tout ce qui est téléchargé. Ils existent depuis quelques temps pour la plupart des langages. Côté Java, Maven ou Gradle permettent entre autres choses de gérer les dépendances du projet. Composer est à peu de chose prêt le seul à être utilisé côté PHP.

Au niveau javascript, il aura fallu attendre nodejs pour en profiter. De nous jours, il y a principalement deux solutions : npm et bower.

NPM and Bower

NPM est historiquement lié à node (acronyme de Node Package Manager), mais se vante, à raison, de permettre l’installation de dépendances pour node.js, io.js, le navigateur et autres.

Il est devenu incontournable pour tout développeur web car il sert à installer à peu près tout ce dont un projet peut avoir besoin : librairies, outils, système de build et ironiquement Bower, qui lui est exclusivement destiné aux dépendances client.

NPM versus Bower

Si on devait s’en ternir à qui a la plus grosse, le premier dispose de plus de 150 000 packages à ce jour, contre un peu plus de 27 000 pour le second. L’utilisation de packages npm côté client peut nécessiter l’utilisation de Browserify, mais la plupart des dépendances peuvent s’en passer.

L’installation des packages est très similaire dans les deux cas :

npm install --save jquery
bower install --save jquery

Les dépendances sont listées dans un fichier (qui DOIT être dans le dépôt, à la différence des dépendances elles-mêmes). Qui, là encore, semblent très proches :

package.json

{
  "name": "test",
  "version": "1.0.0",
  "dependencies": {
    "jquery": "^2.1.4"
  }
}

bower.json

{
  "name": "test",
  "version": "1.0.0",
  "dependencies": {
    "jquery": "~2.1.4"
  }
}

Non, je vous assure, ce n’est pas une erreur de copié-collé.

Les dépendances sont par défaut installées dans un dossier node_modules ou bower_components – qui rappelons-le, ne doivent pas être commit dans les dépôts !

Les différences sembles donc assez mineures. En fait, une seule grosse différence subsiste entre les deux systèmes : la gestion des dépendances des packages installés. Sous npm, chaque module dispose de ses propres dépendances, tandis que sur bower, tout est partagé. On parle de nested dependency tree pour le premier et de flat dependency tree au niveau du second. Ce qui implique pour bower, en cas de conflit, de devoir régler manuellement le problème (si deux modules nécessitent deux versions de jquery différentes par exemple). Et au niveau de npm, un gros dossier node_modules.

Alors, lequel utiliser ?

Globalement, peu importe, l’idée générale est d’arrêter de gérer manuellement ses dépendances et surtout de ne plus les avoir dans les dépôts.

A mon sens, il est tout de même dommage d’installer un outil supplémentaire alors que npm fait déjà le boulot. C’est un débat qui court depuis quelques temps déjà, et ce même dans le dépôt officiel de bower.

Pour aller plus loin

TAGS: , BY: Michael Cellier 0 COMMENT
LIRE LA SUITE

Michael Cellier

Laisser un commentaire