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.

✨ Cet article a été actualisé en Août 2020 pour suivre les évolutions du domaine.

📝 Définition

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 d'une bibliothèque vont y publier chaque nouvelle version 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, ou bien il est possible qu'une dépendance ait encore bien d'autres dépendances, il faut parfois correctement installer ces dernières sous le bon utilisateur et parfois les compiler, etc. Bref, il vaut mieux que le package manager soit rodé.

🐦 Maintenant, en JavaScript...

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 ou une application 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 cela peut aussi s'automatiser !

Un des premiers package manager à apparaître dans le monde JavaScript avec une forte notoriété est Bower, sorti en 2012 par les développeurs de chez Twitter, qui étaient à cette époque en train d'open-sourcer pas mal de leurs outils (Bootstrap entre autres). 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. Aujourd'hui, Bower est n'est plus maintenu, car l'autre package manager sorti peu avant lui allait finir par être celui par défaut.

😎 Node débarque

Parlons désormais de npm, arrivé au sein de Node.js vers 2010. En effet, pour les équipes de Node.js, qui dit "on invente le développement back-end en JavaScript" dit qu'il faudra bien devoir créer quelque chose pour gérer les dépendances. En 2020, npm finira même par être racheté par GitHub.

npm se compose à la fois de l'outil en ligne de commande, mais aussi d'un répertoire en ligne de paquets, et les équipes de Node.js étant derrière tout ça, on avait donc quelque chose de confiance qui allait forcément être durable.

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 fameux 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.

Il finira même par être utile pour des projets pas forcément JavaScript, mais utilisant des packages disponibles sur ses dépôts, par exemple des bibliothèques de compilation, des task runners, etc.

🧶 La surprise Yarn

Facebook, s'était déjà frayé un nom dans le monde de l'open-source et du Javascript, rends disponible en 2016 son propre package manager : Yarn. Né de nombreuses contraintes qu'ont pu rencontrer leurs développeurs sur des projets front-end, il approche le rôle d'un package manager d'une tout autre façon dans sa conception, pour proposer une installation des dépendances d'un projet de façon bien plus sûre mais surtout terriblement plus rapide. Bien sûr, vu qu'il utilise les dépôts officiels de npm, son usage est très similaire à ce dernier.

Aussi, depuis la sortie de Yarn, npm n'a cessé de s'améliorer à chaque nouvelle version majeure, tentant de réduire le gap de fonctionnalités entre les deux, souvent avec succès d'ailleurs.

🔚 Conclusion

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... mais les performances de Yarn a imposé ce dernier comme un concurrent frontal, si bien qu'aujourd'hui l'on peut au final utiliser l'un ou l'autre selon ses préférences, vu qu'ils utilisent le même dépôt de paquets.

C'était le dernier article de cette série vulgarisant une bonne partie du monde de JavaScript, il était prévu à la base d'en écrire un sur les tasks runners mais vu la chute de leur utilisation (au profit de solutions plus raisonnables) ça ne me semble plus nécessaire d'en parler.