Discussion :

[Firlfire]

Bonjour,

J'ai fait quelques recherches sur le net mais je n'arrive pas a comprendre la différence entre bower, npm et yarn pour installer des packages.
Ils font tous la meme chose non ? Alors pourquoi préférer intaller un gestionnaire de package (bower/yarn) plutot que d'utiliser le gestionnaire de package "par défaut" de nodeJS ?

Merci d'avance!

[Marco46]

Premier point, bower est déprécié et ne doit plus être utilisé. Le site de l'outil lui-même préconise d'utiliser yarn / npm.

Ensuite, il y a une différence de fond entre bower d'un côté et yarn et npm de l'autre. bower est seulement un gestionnaire de téléchargement qui tire les "packages" directement des dépôts (généralement GitHub), c'est à dire en fait le code source des projets. npm et yarn sont les CLI du registre npm qui lui stocke de vrais packages générés par les contributeurs.

Il n'y a pas de véritable gestion des dépendances réalisée par bower, il s'agit plus d'un gestionnaire de téléchargement. L'écosystème autour de npm est lui en revanche un véritable système de gestion des dépendances.

Concernant la différence entre npm et yarn, c'est en fait le même outil (le CLI du registre npm) implémenté 2 fois. yarn a été écrit parce que le CLI npm a longtemps été insatisfaisant pour ne pas dire mauvais sur beaucoup d'aspects (lenteurs, manque de rigueur dans la gestion des dépendances, etc ...) mais ce retard a depuis été comblé par la société gérant le registre npm. Il n'y a aujourd'hui plus de raison objective à l'usage de yarn.

Concernant les raisons de l'existence de bower c'est un peu du même ordre mais pour comprendre il faut avoir une vision de la chronologie de tout ça.

npm est le gestionnaire de dépendance de Node.js, créé donc d'abord pour s'appliquer aux développements backend en JavaScript. Il a été mis en place autour de 2010.

Avec l'arrivée de ES5 et de Node autour de 2009 le développement frontend JavaScript a été le premier à connaître son essort. L'arrivée de bower en 2012 avait pour but de combler le vide dans le domaine de la gestion des dépendances pour les projets JavaScript. Comme les besoins étaient principalement frontend cet outil a été conçu pour résoudre les problématiques front à l'époque où la gestion des modules était balbutiante et chaotique, plusieurs systèmes de modules différents, pas de transpileurs comme Babel ou TypeScript, pas de bundlers comme Webpack ou Rollup. On tirait simplement les dépendances dans un dossier du projet et on reliait tout ça à la main dans index.html.

Puis Node.js a pris de l'ampleur, de nombreux outils ont été développés avec Node.js pour aider les développement frontend, autour de 2012/2013 on a commencé à voir apparaitre les grunt, gulp et bower.

Puis le développement backend a aussi pris de l'ampleur et au bout d'un moment certains développeurs (de chez Facebook je crois) ont été suffisamment agacés par les problèmes récurrents du CLI npm pour créer leur propre outil mais basé sur le même registre. C'est la naissance de yarn et c'est en fait assez récent, autour de 2016.

Voyant que leur CLI commençait à se faire sévèrement attaquer, la société derrière le registre npm a fortement investi dans le développement de leur CLI c'est deux dernières années, et depuis au moins la version 5 il n'y a plus de raison d'utiliser yarn, et encore moins bower.

Donc, en bout de ligne, en 2019 il n'y a aucune question à se poser, que l'on soit en front ou en back, c'est le CLI npm qui doit s'imposer et rien d'autre. Notes que le CLI yarn est parfaitement fonctionnel, mais c'est vraiment se compliquer la vie pour une plus value nulle.

[Firlfire]

Merci pour cette réponse claire!
grunt et gulp sont toujours d'actualités eux non ?

[Marco46]

Non ça sent le sapin. Aujourd'hui on passe par les scripts npm en utilisant directement les outils qui vont bien. Pour le front le plus clair de ce qui était fait avec gulp/grunt est désormais géré par les bundlers out of the box.

Le problème des outils comme grunt et gulp c'est qu'ils nécessitent d'écrire beaucoup de code pour arriver au résultat final (concaténation, injection, minification, etc ...). Les bundlers modernes gèrent tout ça avec très peu de configuration et zéro code à écrire.