Comparaison des gestionnaires de packages JavaScript : Npm vs Yarn vs Pnpm

Il existe trois acteurs principaux dans l'espace des gestionnaires de packages :

• npm

• Yarn

• High-Performance npm (pnpm)

Nous avons en fait des fonctionnalités fondamentalement similaires implémentées dans tous les gestionnaires de packages, vous déciderez donc très probablement lequel utiliser en fonction des exigences non fonctionnelles. Gestionnaire de packages , comme la vitesse d'installation, la consommation de stockage ou la praticité.

Bien sûr, la façon dont vous choisirez d’utiliser chaque gestionnaire de packages sera différente, mais ils ont tous des concepts fondamentalement cohérents. Tous les gestionnaires de packages ci-dessus peuvent exécuter les commandes suivantes :

• Lire et écrire des données
• Installer ou mettre à jour par lots toutes les dépendances
• Ajouter, mettre à jour et supprimer des dépendances
• Exécuter des scripts
• Publier des packages

Cependant, malgré cela, les gestionnaires de packages sont différents sous le capot. Traditionnellement, npm et Yarn installaient les dépendances dans un dossier plat node_modules. (Faites attention à l'ordre ici, yarn est d'abord carrelé et npm était récursif auparavant). Mais le carrelage peut également poser toute une série de problèmes de sécurité.

• Incertitude de la structure de dépendance.

• L’algorithme d’aplatissement lui-même est très complexe et prend beaucoup de temps.

• Les packages avec des dépendances déclarées

• sont toujours accessibles illégalement dans le projet.

Par conséquent, pnpm a introduit de nouveaux concepts dans le dossier node_modules pour stocker les dépendances plus efficacement. Yarn Berry va même plus loin en abandonnant complètement le mode (PnP) de node_modules (plus de détails à ce sujet dans un autre article).

Un bref historique des packages JavaScript

Le premier gestionnaire de paquets publié était npm , en janvier 2010. Il a établi les principes fondamentaux du fonctionnement actuel des gestionnaires de packages. Mais puisque npm existe depuis plus de 10 ans, pourquoi existe-t-il une autre option ? Voici quelques raisons principales pour lesquelles cela pourrait être le cas :

• node_modules a différents algorithmes de résolution de dépendances (imbriqués et en mosaïque, mode node_modules vs PnP) et
• différentes méthodes de levage de dépendances ( hoisting )
• Différents formats locking (performances différentes, comme celle écrite par yarn lui-même)
• Package de stockage sur disque Différents fichiers. formats (efficacité de l'espace différente)
• Prise en charge différente des projets multi-packages (alias workspaces ) qui affectent la maintenabilité et la vitesse des monorepos
• Différents besoins en nouveaux outils et commandes (différents besoins d'extensibilité via des plugins et des outils communautaires)
• Configurabilité et flexibilité différemment

Plongeons-nous dans l'histoire de la façon dont ces aspects ont été déterminés après la montée en puissance de npm , comment Yarn Classic a résolu certains de ces problèmes, comment pnpm a étendu ces concepts et comment Yarn Berry , en tant que successeur de Yarn Classic brise ces concepts et processus traditionnels.

Pioneer npm

npm est le créateur des gestionnaires de packages. Beaucoup de gens croient à tort que npm est un acronyme pour « Node package manager », mais ce n'est pas le cas.

Sa sortie a constitué une révolution car auparavant, les dépendances des projets étaient téléchargées et gérées manuellement. npm a introduit des éléments tels que les fichiers et leurs champs de métadonnées, le stockage des dépendances dans node_modules , des scripts personnalisés, des packages publics et privés, etc.

En 2020, GitHub a acquis npm, donc en principe npm est désormais géré par Microsoft. Au moment de la rédaction de cet article, la dernière version majeure est la v8, sortie en octobre 2021.

Innovator Yarn Classic

En octobre 2016, Facebook a annoncé un partenariat avec Google et un certain nombre d'autres sociétés pour développer un nouveau gestionnaire de packages (engineering.fb.com/2016/10/11/…) afin de répondre à la cohérence alors existante de npm. problèmes de sécurité et de performances. Ils ont nommé le fil de remplacement.

Bien que Yarn soit toujours architecturé et conçu sur la base de nombreux concepts et processus de npm , Yarn a eu un impact significatif sur le domaine des gestionnaires de packages. Par rapport à npm , Yarn parallélise les opérations pour accélérer le processus d'installation, ce qui constituait un problème majeur avec les versions antérieures de npm .

Yarn a établi des normes plus élevées en matière de lecture et d'écriture, de sécurité et de performances, et a inventé de nombreux concepts (plus tard, npm a également apporté de nombreuses améliorations à cela), notamment :

• monorepo prend en charge
• la mise en cache, l'installation du
• verrouillage des Locking
• de téléchargement hors ligne
(Locking)

Yarn v1 dans Entrer en mode maintenance dans 2020. Depuis lors, la série v1.x est considérée comme héritée et renommée Yarn Classic . Son successeur Yarn v2 (Berry) est désormais la branche de développement la plus active.

pnpm plus efficace

La version 1 de pnpm a été publiée en 2017 par Zoltan Kochan. C'est un remplacement pour npm , donc si vous avez un projet npm , vous pouvez utiliser pnpm tout de suite !

La principale raison pour laquelle pnpm a été créé est que npm et Yarn sont très redondants en termes de structures de stockage de dépendances utilisées dans les projets. Bien que Yarn Classic ait un avantage en termes de vitesse par rapport à npm , il utilise la même méthode de résolution de dépendances que pnpm : npm et Yarn Classic utilisent hoisting pour aplatir leurs node_modules .

Au lieu d'optimiser la structure précédente, pnpm introduit Une autre stratégie de résolution de dépendances est proposée : a. structure de stockage orientée contenu. Le dossier node_modules généré par cette méthode repose en fait sur le répertoire ~/.pnpm-store/ qui est globalement stocké sur le dossier principal. Chaque version des dépendances est physiquement stockée une fois dans ce dossier répertoire, formant une adresse source unique pour économiser un espace disque considérable.

La structure node_modules est une structure imbriquée de dépendances créée à l'aide symlinks (où chaque fichier/package dans un dossier est stocké via un lien physique). La figure suivante de la documentation officielle illustre cela. (Photos à remplir : liens soft et hard)

L'influence de pnpm est visible dans le rapport 2021 : en raison de leurs innovations en matière de stockage adressable par contenu, les concurrents cherchent à adopter les concepts pnpm , tels que la structure des liens symboliques et la gestion efficace des disques des packages.

Yarn (v2, Berry), réinventant la roue avec Plug'n'Play

Yarn 2, est sorti en janvier 2020 et a été présenté comme une mise à niveau majeure du Yarn original. L'équipe Yarn l'appelle Yarn Berry pour montrer plus clairement qu'il s'agit essentiellement d'un nouveau gestionnaire de packages avec une nouvelle base de code et de nouveaux principes.

La principale innovation de Yarn Berry est son approche plug-and-play (PnP) comme stratégie de réparation des node_modules. Au lieu de la stratégie de génération de node_modules , générez un fichier .pnp.cjs avec une table de recherche de dépendances, ce qui permet une gestion plus efficace des dépendances puisqu'il s'agit d'un fichier unique plutôt que d'une structure de dossiers imbriquée. De plus, chaque package est stocké dans un dossier sous la forme d'un fichier zip au lieu de .yarn/cache/ , et prend moins d'espace disque que node_modules .

Tous ces changements se sont produits si rapidement qu’ils ont suscité de nombreuses controverses après leur publication. De telles modifications majeures apportées à PnP obligent les responsables à mettre à jour leurs packages existants pour qu'ils soient compatibles avec celui-ci. Utiliser la nouvelle approche PnP par défaut et revenir à node_modules n'était pas simple au départ, ce qui a conduit de nombreux développeurs bien connus à ne pas l'envisager et à critiquer publiquement Yarn 2.

Depuis lors, l’équipe Yarn Berry a résolu de nombreux problèmes dans ses versions ultérieures. Pour résoudre les problèmes d'incompatibilité PnP, l'équipe a proposé un moyen de modifier facilement le mode de fonctionnement par défaut. Avec l'aide du plugin node_modules, revenir à l'approche traditionnelle node_modules ne nécessite qu'une seule ligne de configuration.

De plus, l'écosystème JavaScript a fourni une prise en charge croissante du PnP au fil du temps, et comme vous pouvez le voir dans ce tableau de compatibilité, certains grands projets ont commencé à adopter Yarn Berry .

Même si Yarn Berry est encore jeune, il a déjà un impact sur le domaine des gestionnaires de paquets : pnpm a adopté l'approche PnP fin 2020.

Flux de travail d'installation

Le gestionnaire de packages doit d'abord être installé sur les systèmes locaux et CI/CD de chaque développeur.

npm

npm est livré avec Node.js , aucune étape supplémentaire n'est donc requise. En plus de télécharger le programme d'installation de Node.js pour votre système d'exploitation, il est devenu courant d'utiliser les outils CLI pour gérer les versions logicielles. Dans le contexte de Node, Node Version Manager (nvm) ou Volta est devenu un utilitaire très pratique.

Yarn Classic et Yarn Berry

Vous pouvez installer Yarn 1 de différentes manières, par exemple, en tant que package npm : .$ npm i -g yarn

Pour migrer de Yarn Classic vers Yarn Berry, la méthode recommandée est la suivante :

• Installer ou mettre à jour Yarn Classic vers

To mettez à niveau vers la dernière

• version

moderne,

• utilisez la commande

  Yarn Set Version Berry.

Cependant, la méthode recommandée pour installer Yarn Berry ici est via Corepack.

Corepack a été créé par les développeurs de Yarn Berry. L'initiative s'appelait à l'origine Package Manager Manager (pmm) et a été fusionnée avec Node dans LTS v16.

Avec l'aide de Corepack, Node est un gestionnaire de paquets alternatif à npm que vous n'avez pas besoin d'installer « séparément » puisqu'il comprend les binaires Yarn Classic , Yarn Berry et pnpm . Ces cales permettent aux utilisateurs d'exécuter des commandes Yarn et pnpm sans les installer explicitement au préalable et sans gâcher la distribution Node.

Corepack est préinstallé avec Node.js ≥ v16.9.0. Cependant, pour les anciennes versions de Node, vous pouvez utiliser ⬇️

npm install -g corepack

pour activer Corepack avant de l'utiliser. Cet exemple montre comment l'activer dans Yarn Berry v3.1.1.

# vous devez d'abord vous inscrire
$ activation du corepack
# cale installée mais la version concrète doit être activée
$ corepack préparer [email protected] --activate

pnpm

Vous pouvez installer pnpm en tant que package npm : $ npm i -g pnpm . Vous pouvez également installer pnpm à l'aide de Corepack :

$ corepack prepare [email protected] --activate

project structure

Dans cette section, vous verrez en un coup d'œil les principales fonctionnalités des différents gestionnaires de packages. Vous pouvez facilement découvrir quels fichiers sont impliqués dans la configuration d'un gestionnaire de packages spécifique et quels fichiers sont générés par l'étape d'installation.

Tous les gestionnaires de packages stockent toutes les méta-informations importantes dans le fichier manifeste du projet package.json. De plus, les fichiers de configuration au niveau racine peuvent être utilisés pour configurer différents packages privés ou différentes configurations de résolution de dépendances.

Lors de l'étape d'installation, dependencies sont stockées dans une structure de fichiers telle que node_modules et un fichier locking est généré. Cette section ne prend pas en compte les paramètres de l'espace de travail. Tous les exemples ne montrent donc qu'un seul emplacement où les dépendances sont stockées.

npm

en utilisant $ npm install ou le plus court $ npm i générerai un fichier package-lock.json et un dossier node_modules . Il existe également des fichiers configurables tels que .npmrc qui peuvent être placés dans le répertoire racine. Consultez la section suivante pour plus d'informations sur locking des fichiers.

.
├── node_modules/
├── .npmrc
├── package-lock.json
└── package.json

Yarn

exécutant $ yarn créera un fichier yarn.lock et un dossier node_modules . Les fichiers .yarnrc peuvent également être des options de configuration, et Yarn Classic prend également en charge les fichiers .npmrc . Vous pouvez également utiliser le dossier de cache .yarn/cache/ et la dernière version Yarn Classic stockée localement dans .yarn/releases/ .

.
├── .fil/
│ ├── cache/
│ └── versions/
│ └── fil-1.22.17.cjs
├── node_modules/
├── .yarnrc
├── package.json
└── Yarn.lock

Yarn Berry : node_modules

En raison de ce mode d'installation spécial, vous devez gérer plus de fichiers et de dossiers dans votre projet Yarn Berry qu'avec d'autres gestionnaires de packages. Certains sont facultatifs et d’autres sont obligatoires.

Yarn Berry ne prend plus en charge .npmrc ou .yarnrc ; il nécessite un .yarnrc.yml. Pour le flux de travail traditionnel de génération de dossiers node_modules , vous devez fournir la configuration nodeLinker pour utiliser la configuration node_modules ou pnpm (je ne comprends pas cette partie).

# .yarnrc.yml
nodeLinker : node-modules # ou pnpm

exécutant $ yarn installera toutes les dépendances dans un dossier node_modules . Et un fichier yarn.lock est généré, qui est plus récent mais non compatible avec Yarn Classic . De plus, un dossier .yarn/cache/ est généré pour une installation hors ligne. Ce dossier est facultatif et sert à stocker la version de Yarn Berry utilisée par le projet.

.
├── .fil/
│ ├── cache/
│ └── versions/
│ └── fil-3.1.1.cjs
├── node_modules/
├── .yarnrc.yml
├── package.json
└── Yarn.lock

Yarn Berry: pnp

Qu'il s'agisse d'un mode strict ou d'un mode lâche pour PnP, l'exécution $ yarn avec .pnp.cjs et yarn.lock générera un .yarn/cache/ et .yarn/unplugged . PnP strict est le mode par défaut. Si vous souhaitez configurer le mode lâche, vous devez l'activer sous la forme suivante⬇️ :

# .yarnrc.yml.
noeudLinker : pnp
pnpMode : loose

Dans un projet PnP, en plus du dossier releases , le dossier .yarn est susceptible de contenir également un dossier sdk/ qui fournit le support IDE. Selon votre cas d'utilisation, .yarn peut même contenir plus de dossiers.

.
├── .fil/
│ ├── cache/
│ ├── versions/
│ │ └── fil-3.1.1.cjs
│ ├── SDK/
│ └── débranché/
├── .pnp.cjs
├── .pnp.loader.mjs
├── .yarnrc.yml
├── package.json
└── fil.lock`

pnpm

est le même que celui npm ou du projet Yarn Classic . pnpm nécessite également le fichier package.json . Après avoir installé les dépendances à l'aide de $ pnpm i j'obtiens un dossier node_modules , mais sa structure est complètement différente puisque son contenu est un stockage adressable.

pnpm génère également son propre fichier de verrouillage pnp-lock.yml . Vous pouvez fournir une configuration supplémentaire à l'aide du fichier .npmrc facultatif.

.
├── node_modules/
│ └── .pnpm/
├── .npmrc
├── package.json

Fichier de verrouillage

pnpm-lock.yml

Comme mentionné dans la section précédente, chaque gestionnaire de packages crée des fichiers de verrouillage.

Le fichier lock stocke la version exacte de chaque dépendance installée par votre projet, permettant une installation plus prévisible et déterministe. Ce fichier lock est important car les versions dépendantes sont susceptibles d'être déclarées avec une plage de versions (par exemple, ≥ v1.2.5) et si vous ne « verrouillez » pas votre version, la version réellement installée peut être différente.

Les fichiers de verrouillage stockent parfois également des sommes de contrôle (un hachage si je me souviens bien), que nous aborderons plus en détail dans la section sur la sécurité.

À partir de npm v5+, le verrouillage des fichiers a toujours été la fonction principale de npm ( package-lock.json ). Dans pnpm , c'est pnpm-lock.yaml . yarn.lock dans Yarn Berry apparaît dans le nouveau format YAML.

Dans la section précédente, nous avons vu l'approche traditionnelle consistant à installer des dépendances dans la structure de dossiers node_modules . C'est la solution utilisée par npm , Yarn Classic et pnpm ( pnpm est plus efficace que les autres).

Yarn Berry fait les choses différemment en mode PnP. Au lieu du dossier node_modules , les dépendances sont stockées dans des fichiers zip sous la forme d'une combinaison de fichiers .yarn/cache/ et .pnp.cjs .

Il est préférable de placer ces fichiers de verrouillage sous contrôle de version, car chaque membre de l'équipe installe la même version, ce qui résout le problème "fonctionne sur votre machine et sur la mienne".

CLI

Le tableau suivant compare les différentes commandes CLI disponibles dans npm , Yarn Classic , Yarn Berry et pnpm . Il ne s’agit en aucun cas d’une liste complète, mais plutôt d’un aide-mémoire. Cette section ne couvre pas les commandes liées au flux de travail.

npm et pnpm ont de nombreux alias de commandes et d'options ad hoc, ce qui signifie que les commandes peuvent avoir des noms différents, par exemple $ npm install vs $ npm add . De plus, de nombreuses options de commande ont des versions abrégées, telles que -D au lieu de --save-dev . Dans le tableau, j'appelle toutes les versions abrégées des alias. À l'aide de chacun de ces gestionnaires de packages, vous pouvez ajouter, mettre à jour ou supprimer plusieurs dépendances.

Gestion de la configuration des dépendances

Ce tableau couvre les commandes de gestion des dépendances utilisées pour installer ou mettre à jour toutes les dépendances spécifiées dans package.json .

Gestion de la configuration de l'installation

L'exemple suivant montre comment gérer les packages pendant le développement. Termes utilisés dans le tableau :

• Package : dépendance ou binaire Binaire
• : Un outil d'exécution depuis node_modules/.bin/ ou .yarn/cache/ (PnP)

Il est important de comprendre que Yarn Berry nous permet uniquement d'exécuter dans package.json ou Expose les fichiers binaires spécifiés dans le fichier bin/ .

Commandes courantes

Ce tableau couvre quelques commandes intégrées utiles. S'il n'y a pas de commande officielle, les commandes tierces peuvent généralement être utilisées via des packages npm ou des plugins Yarn Berry .

Fichier de configuration

La configuration du gestionnaire de packages s'effectue dans votre package.json et dans les fichiers de configuration dédiés.

• Définir la version exacte à utiliser
• Configurer le registre privé
• avec une stratégie de résolution de dépendances spécifique
• Indiquer au gestionnaire de packages où trouver l' monorepo

npm

La plupart des configurations se produisent dans le fichier de configuration privé .npmrc .

Si vous souhaitez utiliser la fonctionnalité workspaces de npm , vous devez ajouter le champ de métadonnées des espaces de travail dans package.json pour indiquer à npm où trouver le sous-projet ou le dossier de l'espace de travail.

//...
  "espaces de travail": [
    "crochets",
    "utils"
  ]
}

Chaque gestionnaire de packages peut utiliser le registre public npm . Vous souhaiterez probablement les réutiliser sans les publier dans un registre public. Vous pouvez configurer ceci pour priver le registre de votre fichier .npmrc . (En gros, tous ont désormais des sources privées)

# .npmrc
@doppelmutzi:registry=https://gitlab.doppelmutzi.com/api/v4/projects/41/packages/npm/

Il existe de nombreuses options de configuration pour npm , il est préférable de les consulter dans la documentation.

Yarn

Vous pouvez définir workspaces de yarn dans package.json (doit être un package privé).

{
  //...
  "privé" : vrai,
  "espaces de travail": ["espace de travail-a", "espace de travail-b"]
}

Toute configuration facultative est placée dans un fichier .yarnrc . Une option de configuration courante consiste à définir un yarn-path: cela oblige chaque membre de l'équipe à utiliser une version binaire spécifiée. yarn-path pointe vers le dossier contenant une version spécifique Yarn (par exemple .yarn/releases/ ). Vous pouvez installer la version unifiée Yarn Classic à l'aide de la commande (classic.yarnpkg.com/en/docs/cli…).

Yarn Berry

La configuration workspaces dans Yarn Berry est similaire à la configuration dans Yarn Classic ( package.json ). La plupart des configurations Yarn Berry se produisent dans .yarnrc.yml et de nombreuses options de configuration sont disponibles.

# .yarnrc.yml
YarnPath : .yarn/releases/yarn-3.1.1.cjs

yarn berry peut utiliser la méthode d'importation $> yarn plugin import <name> pour étendre le plug-in (yarnpkg.com/cli/plugin/…), cette commande également être mis à jour .yarnrc.yml .

# .yarnrc.yml
plugins :
  - chemin : .yarn/plugins/@yarnpkg/plugin-semver-up.cjs
    spec : "https://raw.githubusercontent.com/tophat/yarn-plugin-semver-up/master/bundles/%40yarnpkg/plugin-semver-up.js"

Comme mentionné dans la section historique, pour des raisons de compatibilité, Il peut y avoir des problèmes avec les dépendances en mode PnP strict. Il existe une solution typique à ce type de problème PnP : la politique de configuration des extensions de paquets.

# .yarnrc.yml
Extensions du package :
  "composants stylisés@*":
    dépendances :
      réagir-is : "*"

pnpm

pnpm utilise le même mécanisme de configuration que npm , vous pouvez donc utiliser les fichiers .npmrc . La configuration d'un registre privé fonctionne également de la même manière que l'utilisation npm . Les projets multi-packages peuvent être pris en charge avec la fonctionnalité d'espace de travail de pnpm. Pour initialiser monorepo , vous devez spécifier l'emplacement du package dans le fichier pnpm-workspace.yaml .

#pnpm-workspace.yaml
forfaits :
  - 'packages/**'

Monorepo

Qu'est-ce que Monorepo

(Il y a en fait trois concepts ici, un seul entrepôt et plusieurs projets, un seul entrepôt et un seul projet, et plusieurs entrepôts et plusieurs projets.)

monorepo est un référentiel contenant plusieurs projets. Ces projets sont appelés workspace ou packages. Garder tout au même endroit au lieu d'utiliser plusieurs référentiels est une stratégie d'organisation de projet.

Bien entendu, cela introduit une complexité supplémentaire. Yarn Classic a été le premier à activer cette fonctionnalité, mais désormais, tous les principaux gestionnaires de packages proposent des fonctionnalités d'espace de travail. Cette section montre comment configurer votre espace de travail à l'aide de chacun des différents gestionnaires de packages.

npm

L'équipe npm a publié la fonctionnalité tant attendue d'espace de travail npm dans la v7. Il contient de nombreuses commandes CLI pour faciliter la gestion des projets multi-packages à partir du package racine. La plupart des commandes peuvent être utilisées avec des options liées à workspace pour indiquer npm s'il doit être exécuté sur un espace de travail spécifique, plusieurs ou tous.

# Installation de toutes les dépendances pour tous les espaces de travail
$ npm i --espaces de travail.
# exécuter sur un seul package
$ npm exécuter le test --workspace=hooks
# exécuté sur plusieurs packages
$ npm exécuter le test --workspace=hooks --workspace=utils
# courir contre tous
$ npm exécuter le test --workspaces
#ignorer tous les paquets manquants
$ npm run test --workspaces --if-present

conseils : Par rapport à d'autres gestionnaires de packages, npm v8 ne prend actuellement pas en charge le filtrage avancé ou l'exécution parallèle de plusieurs commandes liées à l'espace de travail.

Yarn

En août 2017, l'équipe Yarn a annoncé la prise en charge monorepo pour la fonctionnalité de l'espace de travail. Auparavant, les gestionnaires de packages ne pouvaient être utilisés que dans des projets multi-packages avec des logiciels tiers tels que Lerna. Ce nouvel ajout à Yarn ouvre également la voie à d'autres gestionnaires de packages pour implémenter une telle fonctionnalité.

Si vous êtes intéressé, vous pouvez vous référer à la façon d'utiliser la fonction d'espace de travail de Yarn Classic avec et sans Lerna. Mais cet article ne présentera que quelques commandes nécessaires pour vous aider à gérer les dépendances dans la configuration Yarn Classic .

# Installer toutes les dépendances $yarn pour tous les espaces de travail 
# Afficher l'arborescence des dépendances $ informations sur les espaces de travail de fil 
# Exécutez un autre package pour démarrer $ Yarn Workspace Awesome - Démarrage du package
  # Ajouter Webpack au package $ Yarn Workspace Awesome - Package Add - D webpack
  # add React pour tous les packages $ Yarn Add React -W

Yarn Berry

Yarn Berry propose des espaces de travail depuis le début, car son implémentation est basée sur les concepts de Yarn Classic . Dans un commentaire sur Reddit, le développeur principal de Yarn Berry a fourni un bref aperçu des fonctionnalités orientées espace de travail, notamment :

• $ Yarn Add --interactive : peut réutiliser des versions d'autres espaces de travail lors de l'installation de packages
• $ Yarn Up : met à jour tous les espaces de travail Package
• $yarn workspaces focus : Installez les dépendances pour un seul espace de travail uniquement
• $yarn workspaces foreach : exécutez la commande sur tous les espaces de travail.

Yarn Berry utilise un certain nombre de protocoles qui peuvent être utilisés dans dependencies ou devDependencies du fichier package.json . Parmi eux se trouve le protocole workspace .

Contrairement à l'espace de travail de Yarn Classic , Yarn Berry définit clairement qu'une dépendance doit être l'un des packages de ce monorepo . Sinon, si les versions ne correspondent pas, Yarn Berry peut essayer d'obtenir sa version à partir du registre distant.

{
  //...
  "dépendances": {
    "@doppelmutzi/hooks": "espace de travail :*",
    "serveur http": "14.0.0",
    //...
  }  
}

pnpm

Grâce au protocole workspace , pnpm a contribué à un projet monorepo similaire à Yarn Berry . De nombreuses commandes pnpm acceptent les options --recursive (-r) ou --filter qui sont particulièrement utiles dans monorepo . Ses commandes de filtrage natives sont également un excellent complément à Lerna .

# élaguer tous les espaces de travail  
pnpm -r exec -- rm -rf node_modules && rm pnpm-lock.yaml  
# exécuter tous les tests pour tous les espaces de travail avec la portée @doppelmutzi
pnpm test d'exécution récursive --filter @doppelmutzi/`

Performances et efficacité du disque

La performance est un élément clé de la décision de sélection. Cette section présente des benchmarks basés sur un projet de petite et moyenne taille. Voici quelques notes sur l’exemple de projet :

• Aucun des deux ensembles de tests n'utilise la fonctionnalité d'espace de travail.
• Les petits projets spécifient 33 dépendances.
• Les projets moyens spécifient 44 dépendances.

J'ai mesuré chacune de nos variantes de gestionnaire de packages une fois en utilisant trois cas d'utilisation (UC). Pour une évaluation et une explication détaillées, veuillez consulter les résultats du projet 1 (P1) et du projet 2 (P2).

• UC 1 : pas de cache/magasin, pas de fichier de verrouillage, pas node_modules ou .pnp.cjs
• UC 2 : cache/magasin présent, pas de fichier de verrouillage, pas node_modules ou .pnp.cjs
• UC 3 : cache/magasin présent, fichier de verrouillage présent, Sans node_modules ni .pnp.cjs

j'ai utilisé l'outil gnomon pour mesurer le temps consommé par l'installation ( yarn | gnomon ). De plus, j'ai mesuré la taille des fichiers générés $ du -sh node_modules .

sécurisé

npm

npm est un peu trop indulgent en matière de gestion des paquets défectueux et a rencontré certaines vulnérabilités de sécurité qui ont directement affecté de nombreux projets. Par exemple, dans la version 5.7.0, lorsque vous exécutez la commande sudo npm sur un système d'exploitation Linux, vous pouvez modifier la propriété des fichiers système, rendant ainsi le système d'exploitation inutilisable.

Un autre incident s’est produit en 2018 impliquant le vol de Bitcoins. Le package Node.js EventStream a ajouté une dépendance malveillante dans sa version 3.3.6. Ce package malveillant contient une méthode cryptographique qui tente de voler des Bitcoins sur la machine du développeur.

Pour aider à résoudre ces problèmes, les nouvelles versions npm utilisent des algorithmes cryptographiques pour vérifier l'intégrité de vos packages installés. SHA-512.

Yarn

Yarn Classic et Yarn Berry utilisent des sommes de contrôle pour vérifier l'intégrité de chaque paquet depuis le début. Yarn essaie également de vous empêcher de récupérer des packages malveillants qui ne sont pas déclarés dans package.json : si une incompatibilité est trouvée, l'installation est abandonnée.

Yarn Berry en mode PnP ne présente pas les problèmes de sécurité de la méthode traditionnelle node_modules . Par rapport à Yarn Classic , Yarn Berry améliore la sécurité de l'exécution des commandes. Vous ne pouvez exécuter que les packages déclarés dans package.json . Cette fonctionnalité de sécurité est similaire à pnpm , que je décris ci-dessous.

pnpm

pnpm utilise toujours des sommes de contrôle pour vérifier l'intégrité de chaque package installé avant d'exécuter son code.

Comme nous l'avons mentionné ci-dessus, npm et Yarn Classic ont tous deux des problèmes de sécurité en raison de la promotion. pnpm évite cette situation car son modèle de gestion n'utilise pas d'élévation ; il génère plutôt des dossiers node_modules imbriqués, éliminant ainsi le risque d'accès illégal aux dépendances. Cela signifie que les dépendances sont déclarées dans .package.json .

Comme nous l'avons vu, cela est particulièrement important dans un contexte monorepo , car le renforcement des algorithmes peut parfois conduire à un non-déterminisme de dépendance.

Utilisation populaire du projet

en conclusion

Il existe en effet de grandes différences dans les principes des différents gestionnaires de packages.

pnpm ressemble initialement à npm en ce que leur utilisation de la CLI est pnpm , mais la gestion des dépendances est très différente; Yarn Classic est toujours populaire, mais il est considéré comme un logiciel hérité et le support peut être abandonné dans un avenir proche. Yarn Berry PnP est tout nouveau, mais son potentiel pour révolutionner le monde des gestionnaires de packages n'est pas encore réalisé.

Au fil des ans, de nombreux utilisateurs ont demandé qui utilise quels gestionnaires de packages, et dans l'ensemble des gens semblent particulièrement intéressés par la maturité et l'adoption de Yarn Berry PnP .

Le but de cet article est de vous fournir plusieurs perspectives pour décider quel gestionnaire de packages utiliser par vous-même. Je voudrais souligner que je ne recommande pas un gestionnaire de packages spécifique. Cela dépend de la façon dont vous pesez les différentes exigences - afin que vous puissiez toujours choisir ce que vous voulez!

Adresse originale anglaise: https://blog.logrocket.com/javascript-package-managers-compared/