Yarn, un n-ième package-manager ?
Tags: yarn, npm, javascript
Published: 2020-04-09 13:50:33

---
title: Yarn, un n-ième package-manager ?
published: true
date: 2016-11-10 12:00:00 UTC
tags: yarn, npm, js, javascript
canonical_url: https://d3rwan.github.io/d3rwan-blog/posts/yarn
---

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](https://code.facebook.com/posts/1840075619545360)

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

## [<svg aria-hidden="true" focusable="false" height="16" version="1.1" viewbox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#mise-en-place)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](https://d3rwan.github.io/d3rwan-blog/media/yarn/yarn_loading.gif)_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.

![](https://d3rwan.github.io/d3rwan-blog/media/yarn/bench.png)

![Benchmark NPM / YARN (source: [https://yarnpkg.com/en/compare](https://yarnpkg.com/en/compare))](https://d3rwan.github.io/d3rwan-blog/media/yarn/bench2.png)_Benchmark NPM / YARN (source: [https://yarnpkg.com/en/compare](https://yarnpkg.com/en/compare))_

Et en réalité ?

Pour comparer les performance entre les deux outils, j’ai utilisé l’utilitaire [npmvsyarn](https://www.npmjs.com/package/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](https://d3rwan.github.io/d3rwan-blog/media/yarn/ex.png)_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.

![](https://d3rwan.github.io/d3rwan-blog/media/yarn/ex2.png)

![Exemple avec un projet React ([redux-webpack-es6-boilerplate](https://github.com/nicksp/redux-webpack-es6-boilerplate)) et un projet Angular ([angular1.4-ES6-material-webpack-boilerplate](https://github.com/shprink/angular1.4-ES6-material-webpack-boilerplate))](https://d3rwan.github.io/d3rwan-blog/media/yarn/ex3.png)_Exemple avec un projet React ([redux-webpack-es6-boilerplate](https://github.com/nicksp/redux-webpack-es6-boilerplate)) et un projet Angular ([angular1.4-ES6-material-webpack-boilerplate](https://github.com/shprink/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](https://www.berriart.com/blog/2016/10/npm-yarn-benchmark/)

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

> _Yarn est entre 2x et 3x plus rapide que npm_

## [<svg aria-hidden="true" focusable="false" height="16" version="1.1" viewbox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#conclusion)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…