Parfois, les outils javascript semblent être des effets de mode. Mais devant le nombre de retours positifs sur projet Yarn, cela doit quand même valoir le coup d'y jeter un coup d’œil.

npm n’est sans doute pas l’outil le plus handicapant de la stack javascript. C’est même franchement bien. Mais, c’est vrai, c’est parfois lent, parfois surprenant dans un worflow d’intégration continue, et le npm shrinkwrap est parfois plus source de problèmes que de solutions. Ce que promet Yarn: de la rapidité et une bonne gestion des versions des modules.

Premier test en local

Yarn s’installe très simplement avec … npm:

npm i -g yarn

Je vais tester sur un projet ayant beaucoup (trop ;) ) de dépendances: le boilereplate javascript de Marmelab. Pour une première installation, après clonage du repo, voilà le comparatif:

npm: 1min 30s
yarn: 1min 17s

Rien de très fulgurant. Le projet n’avait pas de fichier npm-shrinkwrap.json, ni de fait de yarn.lock. Après avoir supprimer le répertoire node_modules, je relance une installation. Maintenant, le résultat est beaucoup plus probant.

npm: 1min 11s
yarn: 15s

Effectivement, une fois le cache chauffé, Yarn est vraiment plus rapide

Yarn dans un docker

Si npm est un peu lent, c’est rarement un problème en cours de développement en local. Par contre, cela peut être plus problématique pour les builds et les tests sur un serveur d’intégration continue. Je conseille donc l’article de Martino Fornasa, Using Yarn with Docker

Conclusion

Il s’agit d’un test très rapide, mais en partie concluant. Je ne pense pas utiliser Yarn sur des projets clients pour le moment. Mais comme outil quotidien pour des tests ou des projets perso, oui, sûrement. Je ne suis pas fan de l’idée que Facebook soit en train de truster tellement d’outils js. Et qui sait, cela mettra j’espère un coup de fouet à l’équipe de npm pour que la v4 revienne avec un gain de performance conséquent.

Note

une cheat-sheet yarn vs npm