JavaScript's Bizarre Adventure - Part 5 : les package managers

JavaScript

Le dernier article de cette série parlant de quelques frameworks JavaScript, ce qui est un sujet plutôt lourd (en atteste le temps nécessaire pour écrire le dit article), nous allons désormais nous attarder sur des points plus précis.

Qui dit langage, dit forcément bibliothèques, qu'elles soient très petites ou immenses, et dit que l'on va forcément développer quelque chose en utilisant certaines de ces bibliothèques. Notre projet aura donc certaines dépendances pour fonctionner. Les package managers ont pour but de répondre à toutes les problématiques liés à cela.


Définition

SouthPark

Restez attentif ou je n'hésiterai pas à vous punir

Un package manager va concrètement télécharger depuis un dépôt toutes les dépendances nécessaires au fonctionnement d'un projet, qu'il soit une application, un site web ou même une bibliothèque.

Il permet bien sûr également de publier son projet dans les dépôts officiels du package manager. Par exemple, les créateurs de jQuery publient à chaque nouvelle version de leur bibliothèque pour que les projets qui en dépendent puissent la télécharger.

Dans le fonctionnement interne du bouzin, c'est plus compliqué que ça en a l'air : il est possible qu'une dépendance doit être à une version très précise pour éviter que tout casse si cette dernière est mise à jour, qu'une dépendance ait encore d'autre dépendances, il faut correctement installer sous le bon utilisateur et parfois les compiler selon l'OS... Bref, il est préférable que le package manager soit rodé.

Maintenant, en JavaScript...

BirdATM

Allez hop, fais péter les dépendances !

Commençons par l'intérêt d'utiliser un outil supplémentaire (en ligne de commande qui plus est) dans le cas d'un site web. Tout d'abord, cela vous évite d'aller sur chaque site web des bibliothèques CSS ou JS utilisées, de télécharger la bonne version et de l'extraire au bon endroit, mais surtout, vous serez sûr d'avoir toujours les bonnes dépendances. Et ça peut aussi s'automatiser !

Malgré le fait que l'on soit en JavaScript, du côté des package managers, on a quasiment fini par converger vers une solution unique qui répond à la plupart des usages, et c'est pas plus mal.

Un des premiers à apparaître avec une forte notoriété est Bower, sorti en 2012 par les développeurs de chez Twitter qui à cette époque étaient en train d'open-sourcer pas mal de leurs outils (Bootstrap en fait partie). C'était une solution aux problèmes naissants vis à vis des dépendances dans le développement front-end, apportés principalement par les nombreuses bibliothèques et frameworks JavaScript côté client (comme vu dans les précédents articles de cette série).

Ainsi, toutes les dépendances d'un projet peuvent être consignées dans un joli petit fichier bower.json placé à la racine de ce dernier. Voilà maintenant quelques exemples de commandes :

  • Créer un fichier de projet bower.json vide : bower init
  • Chercher un paquet : bower search jQuery
  • Installer un paquet : bower install bootstrap

Bower reste en activité et peut très bien être utilisé aujourd'hui, mais disons qu'un autre a fini par lui voler la vedette.

Poussez-vous SVP, Node.js est là

HatersGonnaHate

Haters gonna hate

Je parle là de npm, arrivé au sein de Node.js fin 2011. En effet, pour les équipes de Node.js, qui dit "on invente le développement back-end en JavaScript" dit que l'on va aussi devoir créer quelque chose pour gérer les dépendances.

Au delà de son utilisation pour les projets basés sur Node.js, il a fini par être utilisé pour gérer des dépendances côté front-end et peut donc aisément remplacer Bower. C'est aussi avec npm qu'est né le fichier package.json que l'on place à la racine de son projet, qui permet à la fois de décrire ce dernier (nom, version, auteur, licence...) ainsi que ses dépendances. On peut même distinguer deux types de dépendances : celles nécessaires pour développer le projet et le compiler, les devDependencies, et celles nécessaires pour exécuter le projet s'il utilise Node.js par exemple, les dependencies.

Pour ce qui est de son usage... relisez les exemples de la partie précédente en remplaçant juste bower par npm. Voilà. C'est incroyable.

Conclusion

DealWithIt

Devinez qui a gagné ?

npm est naturellement devenu le package manager de référence quand on travaille avec du JavaScript, que ce soit en front-end ou back-end. En permettant à la fois la gestion des dépendances d'un projet, sa description, sa publication, et même l'exécution de scripts personnalisés (par exemple pour compiler quelque chose, etc), il n'y a franchement pas besoin d'aller chercher plus loin.

Next time on the series...

En parlant justement de scripts spécifiques à un projet, on verra dans le prochain article ce que sont les task runners.

ToBeContinued