Face à face, Yarn vs NPM

Aujourd’hui, on va parler du dernier né des outils indispensables poussé à l’origine par la team Facebook : Yarn. Yarn est un gestionnaire de dépendance rapide. Principalement utilisé pour les dépendances Node.js, Yarn est virtuellement agnostique. Cependant, il prend tout son sens pour pallier à certaines faiblesses de NPM. Cet article va vous permettre de savoir si vous avez besoin de passer à Yarn ou non par rapport à npm.

Installation

npm i -g yarn

Celle-ci est une mini-joke, yarn est en effet disponible via npm étant donné qu’il fonctionne merveilleusement pour l’éco-système node.js. Toutefois, Yarn est surtout un binaire installable sur n’importe quel OS et disponible dans les dépôts de la plupart des distributions en gérant un, ou au téléchargement pour les autres (tel windows)

Npm est cependant le grand vainqueur à l’installation, car il est livré prêt à l’emploi avec votre version de Node.js, et donc sans installation supplémentaire. De plus, yarn est une sur-couche de npm et ne fonctionne pas sans ce dernier (d’où le fait que le npm -i ne soit finalement pas une grosse blague)

Fonctionnement

Il y a 2 principales différences entre Yarn et Npm du point de vue du fonctionnel.

La première est le traitement parallèle, npm traite le fichier package.json dépendance par dépendance de façon séquentielle. Dès la première installation de votre projet cette parallélisation offre un gain de performance conséquent à son installation (npm i)

La seconde est la présence du fichier yarn.lock créé automatiquement par Yarn dont le rôle est celui réalisé par npm shrinkwrap, à savoir locker les versions M.m.p (semver) des packages que vous installez, afin d’éviter toutes différences d’installation pour du multi-poste. Le gain est là un peu moins flagrant pour Yarn que dans la parallélisation, vue qu’il se contente de nous faire économiser l’usage du shrinkwrap en le faisant automatiquement.

CLI

Presque toutes les commandes npm ont leur équivalent yarn, j’ai bien quelques cas d’utilisation de npm où je n’utilise ni le -S, ni le -D, ni le -g, mais ils ne s’appliquent pas à un projet (là ou yarn prend son sens grâce au yarn.lock), et en plus ces cas d’utilisation survivraient tout de même à l’utilisation du yarn add. Cependant, on voit quand même clairement apparaître le premier défaut de yarn : il est verbeux, point de yarn a ni de yarn i. Déjà yarn c’est 4 lettres :) et en plus pas de raccourci, c’est pratiquement une insulte faite aux développeurs front qui pour gagner du temps doivent faire l’effort d’en perdre.

Mais aussi

• yarn why : Vous explique pourquoi vous avez installé ce que vous avez installé, que ce soit un acte volontaire ou bien une dépendance enfouie qui pollue votre node_modules comme cela ne devrait pas arriver, confère cet article, bon encore faut-il poser la question à yarn.
• yarn licences : Vous craignez (à raison) les licences contaminantes, mais un npm i vous télécharge moultes moultes dépendances dont vous ne savez rien. Découvrir, une à une les 200 licences des 200 répertoires de votre répertoire node_modules ne vous enchante guère. yarn licences est fait pour vous, il vous fait un petit résumé bien utile de l’ensemble des licences de vos dépendances et des dépendances de vos dépendances. Bon 99,99% des paquets npm sont en MIT ou en ISC, mais si une GNU GPL se cache, vous en serez notifiés par cette commande.
• --flat : L’option qui permet à npm (yarn) de se déguiser en bower, en n’installant qu’une seule et unique version de chaque dépendance, fini l’arbre débile sans fin de modules dupliqués. Attention du coup aux conflits de version, à utiliser en connaissance de cause.
• yarn clean : l’autoremove d’apt-get au service des modules node, on ne supprime que rarement des dépendances de nos projets, mais quand on le fait, ce petit utilitaire supplémentaire est une killer feature qui fait cruellement défaut à npm, supprimer les dépendances qui ne sont plus lié par package.json d’une façon ou d’une autre est une chose indispensable. (un rm -rf node_modules suivi de npm i faisait toutefois le travail auparavant)

Et bien d’autres petits outils moins utile mais sympathiques pour faciliter notre vie dans le futur (et le présent).

Stabilité

Yarn est encore en version 0.X, à ce titre n’est pas totalement safe selon ses auteurs et il y a effectivement encore plus de 600 issues ouvertes. Cependant, les fix sont émis à une vitesse conséquente et l’adhésion de la communauté est forte donc l’outil a trouvé sa place et couvre déjà la plupart des cas d’utilisation nominaux. En général, on utilise npm en développement plus qu’à l’installation en production, il est donc facile de fallback vers npm si on tombe sur un bug.

Je recommande donc l’utilisation de npm pour vos livraisons/installations en production, ce qui pour le coup requiert de conserver l’utilisation de npm shrinkwrap. Déjà parce qu’à moins que vous ne soyiez en continuous delivery, ça arrive moins souvent que sur votre poste de développement et donc c’est moins grave si ça prend un peu de temps. De toute façon en continuous delivery le temps n’est pas dramatique vu que vous ne surveillez pas l’installation non plus. Et surtout parce que même si la possibilité d’un bug en prod alors que cela fonctionne sur votre poste de dev est minimale, s’il y a une installation à sécuriser c’est celle-ci.

Par contre, sur votre poste de développement, foncez sur Yarn, déjà parce que vous allez gagner du temps, mais aussi parce que c’est le futur, il ne remplacera jamais npm (il l’utilise souvenez vous) mais il l’encapsulera tellement que plus personne n’utilisera npm à l’avenir, autant être prêt dès maintenant.

Conclusion

Yarn est le nouveau npm + bower + ??? réunis, npm par encapsulation, bower gràce au –flat et le reste parce qu’il le permet. Gardez en tête que yarn n’est qu’une surcouche maligne, et que maligne c’est à la fois une forme d’intelligence et de fourberie.

Voilà c’était un short sur yarn car j’ai été pas mal overbooké ces derniers temps, je vous promets une prochaine publication un peu plus velue d’ici 3 semaines.