Yarn est l'un des principaux gestionnaires de paquets JavaScript, développé en 2016 par Sebastian McKenzie de Meta (anciennement Facebook) pour l'environnement d'exécution JavaScript Node.js. Alternative au gestionnaire de paquets npm, Yarn a été créé dans le cadre d'une collaboration entre Facebook (aujourd'hui Meta), Exponent (aujourd'hui Expo.dev), Google et Tilde (la société derrière Ember.js) afin de résoudre les problèmes de cohérence, de sécurité et de performance liés aux grandes bases de code.Aujourd'hui, après plus d'un an de travail, la première version de la ligne de publication 4.x peut enfin posséder l'étiquette "stable"! Pour fêter cela, l'équipe de Yarn nous offre un tour d'horizon des principaux changements. Si vous souhaitez une liste plus détaillée, jetez un coup d'œil au journal des modifications.
Changements majeurs
Voici ce que vous devez savoir lorsque vous mettez à jour des projets 3.x :
- On a maintenant besoin de Node.js 18+.
- Les nouveaux projets créés avec yarn init n'activeront plus Zero-Install par défaut.
- Les nouveaux projets créés avec yarn init utiliseront Corepack plutôt que yarnPath.
- Tous les plugins officiels (typescript, interactive-tools, ...) sont maintenant inclus par défaut.
- La commande yarn workspaces foreach a une syntaxe légèrement modifiée.
Installation de Yarn
Depuis la version 2.0, il est recommandé d'installer Yarn par projet en utilisant le paramètre yarnPath (défini automatiquement par yarn init -2 et yarn set version). L'équipe de Yarn ne publie volontairement pas de versions modernes sur le paquet npm yarn, afin de ne pas casser les projets plus anciens qui n'ont pas encore migré.
À cette fin, il était habituel de recommander l'utilisation du paramètre yarnPath pointant vers un binaire vérifié, mais ce modèle a augmenté les frictions plus qu'ils ne le souhaitaient - de nombreuses personnes n'aimaient pas l'idée d'ajouter un binaire à leur référentiel, même s'il était petit. Ils ont écouté et travaillé conjointement avec Node.js sur un projet appelé Corepack. Corepack est un outil livré avec Node.js 16+ qui sélectionnera automatiquement la bonne version du gestionnaire de paquets à exécuter en fonction du projet sur lequel vous travaillez.
Maintenant que Corepack est livré avec Node 18 et 20, il n'est plus besoin de s'appuyer sur yarnPath, et l'équipe de Yarn a donc mis à jour son guide d'installation pour le refléter. Les commandes yarn init -2 et yarn set version ont été mises à jour pour favoriser la mise à jour du champ packageManager lorsque cela est possible.
INFO
Corepack sait quelle version du gestionnaire de paquets utiliser grâce au champ standard packageManager dans votre package.json. Ce champ sera typiquement défini par l'une des commandes suivantes : yarn init -2, yarn set version x.y.z, ou la commande plus générique corepack use yarn@x.y.z.
Corepack sait quelle version du gestionnaire de paquets utiliser grâce au champ standard packageManager dans votre package.json. Ce champ sera typiquement défini par l'une des commandes suivantes : yarn init -2, yarn set version x.y.z, ou la commande plus générique corepack use yarn@x.y.z.
Yarn tente de vous protéger contre les attaques courantes, et ceci est poussé encore plus loin par l'introduction du mode renforcé. Lorsqu'il fonctionne dans ce mode, Yarn effectue deux validations supplémentaires :
- Il validera que les résolutions stockées dans le fichier de verrouillage sont cohérentes avec ce que les plages pourraient résoudre.
- Il validera que les métadonnées du paquetage stockées dans le fichier de verrouillage sont cohérentes avec les métadonnées du registre distant.
Ensemble, ces vérifications empêcheront tout attaquant de modifier subrepticement vos fichiers de verrouillage lorsqu'il effectue des PR sur votre projet à l'aide de Yarn.
ASTUCE
Le mode renforcé est activé en activant enableHardenedMode, mais il est aussi automatiquement activé lorsque Yarn détecte qu'il s'exécute au sein d'une pull request GitHub sur un dépôt public. Ceci peut être désactivé en désactivant explicitement enableHardenedMode dans votre fichier yarnrc.
Le mode renforcé est activé en activant enableHardenedMode, mais il est aussi automatiquement activé lorsque Yarn détecte qu'il s'exécute au sein d'une pull request GitHub sur un dépôt public. Ceci peut être désactivé en désactivant explicitement enableHardenedMode dans votre fichier yarnrc.
ATTENTION
Les installations fonctionnant sous les contraintes du Hardened Mode sont significativement plus lentes que d'habitude car elles doivent effectuer de nombreuses requêtes réseau qui seraient ignorées autrement. Nous ne recommandons pas de l'activer par défaut - si vous en avez besoin dans un travail de CI spécifique, activez-le via une variable d'environnement :
Les installations fonctionnant sous les contraintes du Hardened Mode sont significativement plus lentes que d'habitude car elles doivent effectuer de nombreuses requêtes réseau qui seraient ignorées autrement. Nous ne recommandons pas de l'activer par défaut - si vous en avez besoin dans un travail de CI spécifique, activez-le via une variable d'environnement :
| Code : | Sélectionner tout |
export YARN_ENABLE_HARDENED_MODE=1
Yarn est le seul gestionnaire de paquets à implémenter un moteur de contraintes. Si vous ne le savez pas, cette fonctionnalité vous permet de définir un ensemble de règles que votre projet doit respecter. Par exemple, le dépôt Yarn impose qu'aucun espace de travail ne dépende de versions différentes d'une dépendance donnée, à moins que cela ne soit explicitement autorisé.
Le moteur de contraintes était alimenté par Tau-Prolog, une implémentation JavaScript de Prolog. Contrairement aux langages impératifs comme JavaScript, Prolog utilise un modèle différent appelé programmation logique - vous définissez que quelque chose existe si une règle est vraie. Il s'agit d'un modèle très intéressant qui s'intègre bien dans le concept de linting basé sur des règles. Malheureusement, Prolog s'est avéré très complexe à utiliser, augmentant la courbe d'apprentissage des contraintes au-delà du seuil avec lequel nous étions à l'aise.
En conséquence, les contraintes Prolog sont dépréciées à partir de Yarn 4, et elles ont été remplacées par un nouveau moteur basé sur JavaScript, avec le support optionnel de TypeScript ! Yarn écrit ses propres règles chez Datadog avec ce framework depuis quelques mois maintenant, avec beaucoup de succès. Vous pouvez également consulter le dépôt public Yarn pour un exemple pratique du type de règles que vous pouvez appliquer au niveau du dépôt, et la documentation récemment remaniée est là pour vous aider à vous familiariser rapidement avec le système.
ASTUCE
Le nouveau paramètre optionnel enableConstraintsChecks permet à Yarn d'exécuter vos contraintes dans le cadre de Yarn install. C'est un moyen pratique de faire remonter les erreurs avant d'avoir à attendre que le CI distant les soulève, et puisque le nouveau moteur est si rapide, il n'a presque aucun impact sur votre temps d'installation
Le nouveau paramètre optionnel enableConstraintsChecks permet à Yarn d'exécuter vos contraintes dans le cadre de Yarn install. C'est un moyen pratique de faire remonter les erreurs avant d'avoir à attendre que le CI distant les soulève, et puisque le nouveau moteur est si rapide, il n'a presque aucun impact sur votre temps d'installation
Diverses fonctionnalités de Yarn étaient livrées sous forme de plugins sideloadés qui devaient être gérés séparément du bundle principal. Bien que cela nous ait aidé à construire un écosystème de plugins, cela s'est avéré difficile à gérer pour nos utilisateurs. Nous avons implémenté quelques fonctionnalités pour rendre cela plus facile (mise à jour automatique des plugins lors de la mise à jour automatique de Yarn), mais au final, les quelques KiBs que nous avons gagnés en ne livrant pas toutes les fonctionnalités par défaut ne valaient pas la confusion et les frictions qu'elles ont causées.
En conséquence, bien que Yarn supporte toujours les plugins tiers (et continuera à le faire dans le futur), toutes les fonctionnalités et commandes que nous construisons sont maintenant disponibles dans la distribution principale. Vous pouvez maintenant utiliser yarn upgrade-interactive et yarn stage sans plugins et, si vous avez configuré TypeScript dans votre projet, Yarn ajoutera et supprimera automatiquement les paquets @types chaque fois que vous mettrez à jour vos dépendances avec yarn add et yarn remove.
Interface utilisateur améliorée
Plusieurs parties de l'interface utilisateur ont été réorganisées pour mieux transmettre l'information. Par exemple, yarn install vous indique maintenant les paquets que vous avez ajoutés, et leur poids total. Vous remarquerez également qu'il n'affiche plus autant d'avertissements concernant les dépendances des pairs, car nous essayons maintenant de n'afficher des avertissements que dans les situations où il est possible d'agir :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 | ➤ YN0000: · Yarn 4.0.0 ➤ YN0000: ┌ Resolution step ➤ YN0085: │ + next@npm:13.5.4, react-dom@npm:18.2.0, and 24 more. ➤ YN0000: └ Completed in 0s 280ms ➤ YN0000: ┌ Fetch step ➤ YN0013: │ 22 packages were added to the project (+ 177.72 MiB). ➤ YN0000: └ Completed in 3s 723ms ➤ YN0000: ┌ Link step ➤ YN0000: └ Completed ➤ YN0000: · Done with warnings in 4s 123ms |
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 | ├─ cacheFolder │ ├─ Description: Folder where the cache files must be written │ ├─ Source: │ └─ Value: '/Users/global/.yarn/berry/cache' │ └─ enableHardenedMode ├─ Description: If true, automatically enable --check-resolutions --refresh-lockfile on installs ├─ Source: └─ Value: null |
La 4.0 n'est pas en reste en matière d'amélioration des performances, et se montre nettement plus rapide à l'installation que la 3.6. Par exemple, voici la différence de temps pour installer Gatsby et son arbre de dépendances de ~350MiB à partir d'un cache froid. L'amélioration de 3x des performances est due à un nouveau cache de métadonnées de paquets qui améliore significativement les performances des installations répétées :
| Code : | Sélectionner tout |
hyperfine -L v stable,canary --prepare 'rm -rf ~/.yarn/berry/cache' 'cd $(mktemp -d) && yarn init -2 && yarn set version {v} && yarn && yarn add gatsby --mode=skip-build'
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 | Benchmark 1: 3.6.0 Time (mean ± σ): 65.599 s ± 2.214 s [User: 82.952 s, System: 8.638 s] Range (min … max): 62.167 s … 68.277 s 10 runs Benchmark 2: 4.0.0 Time (mean ± σ): 16.724 s ± 0.928 s [User: 14.622 s, System: 5.743 s] Range (min … max): 15.318 s … 18.110 s 10 runs Summary 4.0.0 ran 3.92 ± 0.25 times faster than 3.6.0 |
Un site web élégant
Comme vous l'avez probablement remarqué, notre site web a bénéficié d'une refonte majeure, tant au niveau du style que du contenu ! Nous avons travaillé sur cette nouvelle itération pendant plus d'un an, et nous espérons qu'elle vous aidera à trouver de meilleures informations, plus rapidement qu'auparavant.
Quelques améliorations particulières :
- Toutes les commandes référencées ont maintenant un lien vers leur documentation (yarn install)
- Toutes les options référencées ont maintenant une infobulle expliquant leur but (yarn --immutable-cache)
- La plupart des pages ont été réécrites pour être à la fois simplifiées et clarifiées lorsque c'était nécessaire.
- La page des paquets affiche maintenant diverses vérifications configurables, comme par exemple si un paquet supporte CJS, ESM, a des types, ...
Notre expertise se situe plus dans l'outillage que dans la construction de sites web, donc je suis sûr qu'il reste encore des choses à améliorer - en particulier en ce qui concerne le temps de chargement. Si vous souhaitez nous aider, consultez les sources et n'hésitez pas à nous envoyer des PRs !
Mot de la fin
La transition de Yarn 3 à Yarn 4 a été longue, avec pas moins de 53 versions candidates en cours de route, mais nous y sommes finalement parvenus ! Notre objectif pour cette nouvelle itération a été de réduire la courbe d'apprentissage de Yarn et d'améliorer votre expérience utilisateur, sans que la migration ne vous paraisse insurmontable. Nous avons fait des efforts concertés pour éviter de faire des changements importants sans avoir des moyens de migrer automatiquement les projets, donc si vous rencontrez des problèmes que vous pensez que le logiciel aurait dû résoudre, partagez vos commentaires avec nous sur Discord.
Pour ce qui est de l'avenir, il est un peu trop tôt pour donner une réponse définitive, mais je peux vous dire que je suis particulièrement intrigué par le potentiel des constructions natives de Yarn. Les performances ont été sous les feux de la rampe dernièrement, et je me demande parfois quelle est la part de Node.js dans le temps d'exécution global. Ceci étant dit, nous ne prévoyons pas d'entreprendre une autre réécriture complète de la base de code, et nous ne voulons pas non plus compromettre les facteurs qui rendent Yarn si convivial pour les contributeurs, donc les spécificités, ainsi que le calendrier, sont encore à l'étude.
En attendant, nous allons continuer à construire sur nos fondations existantes pour le moment. De l'achèvement du CLI et des commandes de l'interface utilisateur à la réduction de la courbe d'apprentissage et à l'entretien général, nous avons un large éventail d'améliorations en vue. À la prochaine fois !
La transition de Yarn 3 à Yarn 4 a été longue, avec pas moins de 53 versions candidates en cours de route, mais nous y sommes finalement parvenus ! Notre objectif pour cette nouvelle itération a été de réduire la courbe d'apprentissage de Yarn et d'améliorer votre expérience utilisateur, sans que la migration ne vous paraisse insurmontable. Nous avons fait des efforts concertés pour éviter de faire des changements importants sans avoir des moyens de migrer automatiquement les projets, donc si vous rencontrez des problèmes que vous pensez que le logiciel aurait dû résoudre, partagez vos commentaires avec nous sur Discord.
Pour ce qui est de l'avenir, il est un peu trop tôt pour donner une réponse définitive, mais je peux vous dire que je suis particulièrement intrigué par le potentiel des constructions natives de Yarn. Les performances ont été sous les feux de la rampe dernièrement, et je me demande parfois quelle est la part de Node.js dans le temps d'exécution global. Ceci étant dit, nous ne prévoyons pas d'entreprendre une autre réécriture complète de la base de code, et nous ne voulons pas non plus compromettre les facteurs qui rendent Yarn si convivial pour les contributeurs, donc les spécificités, ainsi que le calendrier, sont encore à l'étude.
En attendant, nous allons continuer à construire sur nos fondations existantes pour le moment. De l'achèvement du CLI et des commandes de l'interface utilisateur à la réduction de la courbe d'apprentissage et à l'entretien général, nous avons un large éventail d'améliorations en vue. À la prochaine fois !
Et vous ?
Quel est votre avis sur cette nouvelle version de Yarn ?Voir aussi :
État de JavaScript 2022 : React reste le framework front-end dominant mais est en perte de vitesse côté satisfaction, JQuery est la troisième bibliothèque la plus utilisée Facebook annonce la disponibilité de Yarn, un nouveau gestionnaire de paquets JavaScript « plus rapide, plus fiable » et utilisable hors-ligne Node.js 20.6 est disponible avec une prise en charge des fichiers de configuration .env et l'intégration du garbage collector C++ "Oilpan"