Yarn, un n-ième package-manager ?

Npm, Bower, JSPM… A chaque saison son nouveau package-manager dans l’écosystème JS. Le dernier né, Yarn, a été annoncé il y a quelques semaines par les développpeurs de Facebook. Alors, qu’est-ce que se cache vraiment derrière ce n-ième package-manager ?

Yarn: A new package manager for JavaScript

En premier lieu, Yarn n’a pas l’objectif de remplacer npm ou bower. Il s’agit avant-tout d’un nouveau client ligne de commande permettant la récupération de dépendances depuis le registry npm.

Il propose en outre les améliorations suivantes :

• Performance Optimisation des appels et maximisation de l’utilisation réseau, notamment via un mécanisme d’analyse de l’arbre des dépendances et de parallélisation des requêtes (vs. en série pour npm)
• Déterministe Pour un même projet, les mêmes dépendances seront installées de la même manière sur tous les environnements (plus d’effet “ it works on my machine”)
• Fonctionnement offline Une fois un package installé, il est mis en cache et pourra être installé ensuite sans connexion internet
• Résilience Le processus d’installation est plus robuste, notamment dans le cas de coupure réseau (rejeu des requêtes vs. processus d’installation en erreur)
• Registre multiple Possibilité de récupérer des sources depuis plusieurs registres (npm, bower, github, …)
• Sécurité Utilisation de checksums pour vérifier l’intégrité des dépendances

Mise en place

Pour installer Yarn, le plus simple est encore d’utiliser… npm.

npm install -g yarn

Dès lors, on peut utiliser le client yarn en lieu et place du client npm

# npm install
yarn

# npm init
yarn init

# npm install angular --save
yarn add angular 

# npm install gulp --global
yarn global agg gulp

# npm uninstall angular --save
yarn remove angular

# npm install angular-mocks --save-dev
yarn add angular-mocks --dev

Installation avec Yarn

Pour le reste, on continue d’utiliser le fichier package.json pour lister les dépendances d’un projet, dépendances qui seront toujours stockées dans le répertoire node_modules. Yarn ajoute néanmoins un nouveau fichier yarn.lock. C’est ce fichier qui va garantir l’installation déterministe, puisqu’il va lister chaque dépendance, la version exacte à utiliser, l’ordre d’installation etc… Ce fichier sera crée lors de la première installation par Yarn, puis mis à jour ensuite lors de chaque modification.

Il est important de noter que ce fichier doit être présent sur chaque environnement afin de garantir une installation déterministe, et donc qu’il doit être versionné.

Et les perfs dans tout ca ? Sur un benchmark sur le site de Yarn (donc probablement hyper objectif), les chiffres sont là. C’est vachement plus rapide dans la plupart des cas.

Benchmark NPM / YARN (source: https://yarnpkg.com/en/compare)

Et en réalité ?

Pour comparer les performance entre les deux outils, j’ai utilisé l’utilitaire npmvsyarn qui permet de comparer pour une librairie ou un projet (contenant un package.json) donnés les performances entre l’utilisation de npm & celle de Yarn.

Exemple avec les librairies Angular & React

Concernant l’ajout/suppression d’une librairie seule, Yarn est effectivement plus rapide (jusqu’à 50%), en particulier lorsque le cache et le fichier yarn.lock existe.

Exemple avec un projet React (redux-webpack-es6-boilerplate) et un projet Angular (angular1.4-ES6-material-webpack-boilerplate)

Sur un projet complet, Yarn s’en sort mieux également (jusqu’à 2.5 fois plus rapide). Là encore, on voit que la présence du cache et du yarn.lock améliore d’autant plus les performances.

Bien évidemment, ces exemples sont trop limités pour être représentatifs. Néanmoins, le site berriart.com propose un benchmark plus complet des deux outils sur différents environnements d’intégration continue.

NPM vs Yarn benchmark

Là encore, les résultats vont dans le même sens:

Yarn est entre 2x et 3x plus rapide que npm

Conclusion

Après quelques heures d’utilisation, Yarn semble répondre aux attentes qu’il a suscité: plus rapide que npm, avec des fonctionnalités équivalentes, et une migration sans heurts.

Bien qu’il soit sans doute peut-être un peu tôt pour l’utiliser sur un projet structurant en production, il semble dès aujourd’hui être une alternative crédible au client npm par défaut. On pourra donc facilement l’utiliser sur un nouveau projet ou un projet annexe, afin de confirmer toutes les bonnes prédispositions affichées.

Quant au futur, on ne peut qu’espérer qu’il permette l’amélioration de l’existant, que se soit en poussant à l’amélioration de npm ou en devenant un standard defacto. A moins qu’un petit-nouveau n’arrive d’ici là, et change encore la donne…