Bonjour à tous! Je suis sûr que vous avez vu utiliser différents gestionnaires de packages, c'est-à-dire : des projets Node.js (celui par défaut) npm fil pnpm J'ai vu cela moi-même et j'ai travaillé avec tout ce qui précède, mais j'ai toujours eu une question en tête : qu'est-ce qui pousse les personnes/équipes à utiliser ou au lieu de ? Quels sont les avantages ? Y a-t-il des inconvénients ? fil pnpm npm Eh bien… Découvrons-le ! Règles de comparaison des performances J'ai décidé de comparer , et en termes de leur « vitesse »… npm fil pnpm Vous verrez 3 mesures ci-dessous : Générez un fichier de verrouillage sans aucun cache. Installez les dépendances à partir des fichiers de verrouillage existants sans aucun cache. Installez les dépendances des fichiers de verrouillage existants avec le cache global. Il existe deux types de cache : Mondial. Généralement stocké dans le répertoire personnel de l'utilisateur (fe, ). ~/.yarn/berry/cache Locale. Stocké dans le répertoire du projet (par exemple, ). <project-dir>/.yarn Bien que les cas d'utilisation et soient les cas d'utilisation les plus courants d'après mon expérience, j'ai également pris juste au cas où (bien que ce soit un cas très rare). n°2 n°3 le n°1 J'ai utilisé un exemple de projet de comme exemple de benchmark. create-react-app npm C'est un gestionnaire de packages par défaut pour l'écosystème - que dire d'autre ? Il est livré avec le package d'installation, il est donc fondamentalement prêt à être utilisé lorsque vous installez sur votre machine (ou dans n'importe quel fournisseur si vous y configurez ). Node.js Node.js CI Node.js C'est un énorme « avantage » à mon avis : vous n'avez pas besoin de l'installer séparément ! Rien d'exceptionnel là-bas - ça marche juste ! Et je n'ai vu aucun bug majeur au fil des ans - il semble assez stable et fait le travail. Les fonctionnalités de que j'ai utilisées jusqu'à présent : npm Gérer les dépendances (installer, supprimer, mettre à jour) Publier des packages (privés, publics) Forfaits lien-local Gérer les espaces de travail. Gérer les dépendances stocke les dépendances dans le dossier de la racine de votre projet. Assez simple. npm node_modules ℹ️ stocke des informations sur les registres pour les packages répertoriés - cela s'avère pratique si vous avez des packages d'une seule portée, c'est-à-dire dans différents registres (par exemple - & ) : package-lock.json TRÈS @example-company npm GitHub Packages Voyons maintenant comment il se comporte en termes de vitesse d'installation… Générer package-lock.json sans aucun cache Ça a pris pour que génère un et installe les dépendances sans aucun cache. 1 minute npm package-lock.json Commande utilisée : npm i Installer les dépendances à partir de package-lock.json sans aucun cache Ça a pris pour que installe les dépendances de sans aucun cache. 18 secondes npm package-lock.json Commande utilisée : npm ci Installer les dépendances à partir de package-lock.json avec le cache global Ça a pris pour que installe les dépendances de avec le cache global. 8 secondes npm package-lock.json Commande utilisée : npm ci Gérer les espaces de travail J'ai pu créer et gérer les dépendances pour l'ensemble de l'espace de travail à la fois et pour des projets spécifiques séparément. un espace de travail En d’autres termes, le travail est effectué sans aucun bug/problème, et la documentation officielle est assez simple. Fonctionnalités de Workspace que j'ai utilisées jusqu'à présent : Installez les dépendances pour tous les projets dans l'espace de travail. Installez les dépendances pour un seul projet spécifique. Exécutez un seul script pour tous les projets à la fois et de manière récursive. fil Honnêtement, je n’ai pas beaucoup essayé certaines fonctionnalités . Je veux dire, je l'ai beaucoup utilisé pour « installer des dépendances » en travaillant sur certains projets, et c'est tout à fait ça. du fil n'est pas fourni avec un programme d'installation , vous devrez donc l'installer séparément. Cela signifie qu'il y aurait une étape supplémentaire dans vos pipelines : vous devrez configurer avant d'installer les dépendances de votre projet. Yarn Node.js CI Yarn Gérer les dépendances a deux approches pour installer les dépendances : Yarn « » (par défaut) - crée le dossier et répertorie les packages dans les fichiers et . Zéro installation .yarn yarn.lock .pnp.cjs Un standard - similaire à , stocke les dépendances dans et les répertorie dans le fichier . npm node_modules yarn.lock ℹ️ Les fichiers Lock stockent des informations sur les registres pour tous les packages répertoriés si vous utilisez l'ancienne approche d'installation (normale). Yarn UNIQUEMENT ⚠️ Gardez à l'esprit que « » semble stocker les packages dans le cache local et fournir des liens vers vos fichiers de verrouillage : Zéro installation Cela peut être important pour vous si vous disposez d'un pipeline ou dans lequel vous installez des dépendances dans un environnement propre et que vous souhaitez ensuite les déplacer vers un autre (vous devrez copier à la fois le dossier et le cache local). Dockerfile CI .yarn Étant donné que l'approche par défaut pour le fil est désormais « » et offre de meilleures performances que l'ancienne approche, nous allons enregistrer des benchmarks avec cette approche uniquement. Zéro installation Générer des fichiers de verrouillage sans aucun cache Ça a pris pour que génère un fichier et installe les dépendances sans cache. 16,5 secondes Yarn yarn.lock Commande utilisée : yarn install Installer les dépendances à partir de fichiers de verrouillage existants sans aucun cache Ça a pris pour que installe les dépendances avec l'approche « Zero Install » et sans aucun cache. 11 secondes Yarn Commande utilisée : yarn install --frozen-lockfile Installer les dépendances à partir de fichiers de verrouillage existants avec le cache global Ça a pris pour que installe les dépendances avec l'approche « Zero Install » et le cache global. 8 secondes Yarn Commande utilisée : yarn install --frozen-lockfile Gérer les espaces de travail J'ai pu créer et gérer les dépendances pour tous les projets à la fois et pour des projets spécifiques séparément. un espace de travail Fonctionnalités de Workspace que j'ai utilisées jusqu'à présent : Installez les dépendances pour tous les projets dans l'espace de travail. Installez les dépendances pour un seul projet spécifique. Exécutez un seul script pour tous les projets à la fois et de manière récursive. La documentation est bonne, mais les noms de commandes et les indicateurs prêtent quelque peu à confusion. Par exemple, je dois exécuter ceci pour exécuter le script dans ( ) et le projet imbriqué : test la racine . b2b yarn workspaces foreach -A --include '{.,b2b}' run test En comparaison avec : npm npm run test --workspace=b2b --include-workspace-root pnpm est actuellement à la mode - . pnpm de nombreuses entreprises et projets open source l'utilisent Tout comme , n'est pas fourni avec un programme d'installation , vous devrez donc l'installer séparément. Cela signifie qu'il y aura une étape supplémentaire dans vos pipelines : vous devrez configurer avant d'installer les dépendances de votre projet. Yarn pnpm Node.js CI pnpm Gérer les dépendances est considéré comme … pnpm « » Gestionnaire de paquets rapide et efficace en termes d'espace disque En effet, je suis d'accord avec l'affirmation en termes de gestion locale des dépendances. « efficacité de l'espace disque » Par défaut, déduplique les dépendances partagées. crée des liens symboliques pour les packages utilisés dans plusieurs dépendances. c'est-à-dire que si les packages et utilisent le package comme dépendance, va stocker le package en une seule copie et créer des liens symboliques pour les packages et . De cette façon, le gestionnaire de packages ne crée pas de copies papier et économise de la mémoire sur votre SSD/HDD. pnpm pnpm a b c pnpm c a b ℹ️ ne stocke pas d'informations sur les registres pour les packages répertoriés. pnpm-lock.yaml ⚠️ Gardez à l'esprit que stocke parfois les dépendances dans le cache global, au lieu d'en faire un projet. pnpm Générez pnpm-lock.yaml sans aucun cache Ça a pris pour que génère un et installe les dépendances sans aucun cache. 31 secondes pnpm pnpm-lock.yaml Commande utilisée : pnpm install Installer les dépendances à partir de pnpm-lock.yaml sans cache global Ça a pris pour que installe les dépendances de sans cache. 16 secondes pnpm pnpm-lock.yaml Commande utilisée : pnpm i --frozen-lockfile Installer les dépendances à partir d'un fichier de verrouillage existant avec le cache global Ça a pris pour que installe les dépendances de avec le cache global. 5 secondes pnpm pnpm-lock.yaml Commande utilisée : pnpm i --frozen-lockfile Gérer les espaces de travail Maintenant, c'est là que les choses deviennent vraiment intéressantes… a de nombreuses options de configuration, mais certaines fonctionnalités de base ne fonctionnent tout simplement pas ! pnpm Passons en revue quelques bugs que j'ai rencontrés : pnpm installer --filtre Il est important de pouvoir installer des dépendances pour des projets spécifiques uniquement - c'est très utile pour les monorepos lorsque vous créez des pipelines liés à des projets spécifiques dans l'espace de travail. c'est-à-dire, imaginez que vous avez dans votre espace de travail : une application web, serveur principal, projet de test (tests de bout en bout). Ce sont tous des projets distincts, mais ils font partie du même dépôt ☝️ npm Désormais, vous souhaitez qu’un pipeline exécute uniquement des tests de bout en bout. Donc, vous n’avez besoin que de dépendances de test de bout en bout, n’est-ce pas ? Eh bien, vous ne pourrez pas faire ça - vous oblige à installer des dépendances pour l'ensemble de l'espace de travail ! pnpm était censé installer les dépendances pour les projets sélectionnés uniquement, mais cela ne fonctionne pas. pnpm install --filter <project-name> Il y a un bug vieux d'un an et il a été récemment fermé avec un correctif qui ne fonctionne pas. installation récursive = false installe par défaut les dépendances pour l'ensemble de l'espace de travail (tous les projets) lorsque vous exécutez pnpm pnpm install Vous pouvez alterner ce comportement si vous définissez dans à la racine de votre espace de travail. recursive-install=false .npmrc MAIS . cela introduit un autre bug qui date déjà de presque 2 ans partage-workspace-lockfile=false stocke par défaut la liste des dépendances dans un seul fichier de verrouillage (identique à et ). pnpm npm Yarn Vous pouvez également alterner ce comportement si vous définissez dans à la racine de votre espace de travail. shared-workspace-lockfile=false .npmrc Cela nous permettrait de conserver la fonctionnalité d'espace de travail et d'utiliser l'indicateur pour installer des dépendances pour un projet spécifique. --ignore-workspace Quoi qu'il en soit, ce paramètre introduit quelques problèmes supplémentaires : et génèrent une erreur dans mes pipelines . eslint tsc --noEmit « Heap JavaScript Out of Memory » GitHub Actions Certaines dépendances sont stockées dans le cache global et liées par un lien symbolique dans . node_modules/.pnpm Résultats de comparaison des performances # npm fil pnpm Générer un fichier de verrouillage 60 secondes 16,5 secondes 31 secondes Installer les dépendances sans aucun cache 18 secondes 11 secondes 8 secondes Installer les dépendances avec le cache global 8 secondes 8 secondes 5 secondes Selon le benchmark ci-dessus, est le gestionnaire de paquets le plus lent ☝️ npm Quoi qu’il en soit, interprétons ces résultats… Générer un fichier de verrouillage C'est un cas rare. Habituellement, un fichier de verrouillage est créé lors de l'initialisation du projet, puis se développe lorsque vous installez/mettez à jour des packages. Dans cet esprit, il ne semble pas être une chose très importante sur laquelle s'appuyer lorsque vous choisissez un gestionnaire de packages. Installer les dépendances Dans la plupart des cas, vos projets conservent une liste spécifique de dépendances et vous ajoutez/supprimez rarement quelque chose. Très probablement, vous modifierez les versions de vos packages de temps en temps - ces modifications sont minimes et vous réutiliserez le reste des packages du cache. En d’autres termes, le cas d’utilisation courant est le suivant : récupérer de nouveaux packages dans le registre des packages et récupérer le reste dans le cache. (5-8 sec) est presque deux fois plus rapide que (8-18 sec) avec (8-11 sec) au milieu. pnpm npm du fil Conclusion Faits est en effet - c'est assez clair dans la revue actuelle ! pnpm un gestionnaire de paquets « rapide et efficace sur le disque » La fonctionnalité d'espace de travail est boguée et certains bogues ne sont pas résolus depuis des années. pnpm et nécessitent une configuration supplémentaire dans les pipelines CI, contrairement à . pnpm Yarn npm et ne stockent pas les informations de registre des packages dans leurs fichiers de verrouillage, contrairement à . pnpm Yarn npm Pensées de l'auteur Je pense que fait le meilleur travail si vos exigences en matière de gestionnaire de paquets sont aussi simples que « installer uniquement les dépendances ». pnpm Même si n'est pas fourni avec un programme d'installation prêt à l'emploi, il est facile à configurer dans les pipelines CI avec un ou . pnpm Node.js corepack une action existante Je préfère , parce que : npm c'est stable (surtout les espaces de travail), est livré avec et ne nécessite pas de configuration supplémentaire dans le pipeline CI, Node.js stocke les registres de packages dans afin que vous puissiez installer des dépendances avec une seule portée à partir de différents registres. package-lock.json Ces avantages l'emportent sur les secondes de vitesse et d'espace disque que j'économiserais avec ou . fil pnpm Quels sont vos critères de choix d’un gestionnaire de packages ? Ne soyez pas timide et faites-moi part de vos commentaires dans la section commentaires ci-dessous ! 👇😊
