Un article pour parler des cinq étapes du développement de la gestion des packages Node

Depuis la naissance de Node en 2009, l'écosystème Node s'est développé et a prospéré. Les gestionnaires de packages Node dérivés de l'écosystème Node ont fleuri, et npm, kpm, pnpm, fil, cnpm, etc. sont apparus successivement. En fait, le développement du gestionnaire de packages Node est principalement divisé en 5 étapes. Jetons un coup d'œil aux fonctionnalités clés et aux produits représentatifs de chaque étape~

Phase 1 : Slash and Burn

.

Pour être précis, Node n'existait pas sans gestionnaire de packages. En 2009, lorsque Node.js est sorti, le prototype de npm a également été publié. [Recommandations de tutoriel associées : Tutoriel vidéo Nodejs, Enseignement de la programmation]

npm est le nom complet du gestionnaire de packages Node.js ; de Un bref historique de Node.js vous pouvez voir

2009 
Node.js is born 
The first form of npm is created

Parlons du Package de nœuds qui n'apparaît pas. Comment c'était à l'époque du manager ? Ce que je faisais le plus à cette époque, c'était de chercher le site officiel de chaque logiciel en ligne, comme jQuery

• trouver l'adresse de téléchargement et télécharger le zip ; package ;

• décompressez-le et placez-le dans Dans un répertoire appelé libs dans le projet ;

• Si vous souhaitez le rendre plus pratique, collez directement le lien CDN dans le HTML

• Gestion modulaire en plus temps? Gestion des numéros de versions ? Dépendre de la mise à niveau ? Aucun d’entre eux n’existe !

Phase 2 : Installation imbriquée

En 2009, Node.js est né, et le prototype de npm était également en préparation. La version 1.0 est sortie en 2011 ; npm est conçu autour de l'idée du contrôle de version sémantique ; semver, qui est pris en compte par défaut par les développeurs de packages Node, lors de la mise à niveau du numéro de version personnalisé des packages dépendants, mettra à niveau le numéro de version conformément à la spécification semver.

Synonymes :

Standardisation de la gestion des packages de nœuds, stockage imbriqué dans le répertoire node_modules des dépendances

Produits représentatifs : version npm v1, v2

Caractéristiques clés :

(1) Installation imbriquée de packages dépendants, la même version Les dépendances seront installées de manière redondante (2) Incertitude lors de l'installation du package de dépendances : la dernière version du package de dépendances est installée par défaut (une version fixe peut être définie)

(3) L'installation en série des dépendances est lente, la mise en cache hors ligne n'est pas prise en charge ;

Explication 1 : Dépendance

Installation imbriquée

, si A dépend de B et B dépend de C, le répertoire node_modules est le suivant

node_modules
- package-A
-- node_modules
--- package-B
----- node_modules
------ package-C
-------- some-really-really-really-long-file-name-in-package-c.js

Problème : Trop d'imbrication de dépendances provoquera un enfer d'imbrication, et dans le même temps, un grand nombre d'installations redondantes des mêmes packages dépendants rendront node_modules trop volumineux, obligeant les programmeurs à régulièrement rm -rf node_modules. Cependant, dans les systèmes Windows, de nombreux programmes ne peuvent pas gérer les chemins de fichiers dépassant 260. caractères. Cela a été vu par les premiers utilisateurs Windows de npm. Cette fenêtre contextuelle

Explication 2 : Pour chaque installation de npm, la dernière version des dépendances est installée par défaut, ce qui entraîne l'installation des dépendances

---

incertitude.

Problème : semver standardise la composition du numéro de version : X.Y.Z -[state], la spécification de mise à niveau du numéro de version est la suivante

X est le numéro de version majeur : lorsque les modifications apportées à l'API sont incompatibles avec le ancienne version, mettez à niveau le numéro de version majeure

Y est le numéro de version mineure : une nouvelle API est ajoutée, mais pour des raisons de compatibilité ascendante, le numéro de version mineure de mise à niveau

• Z est le numéro de version du correctif : lorsque des corrections de défauts de compatibilité ascendante sont apportées
• l'état peut être : alpha (test interne), bêta (test public), version gamma (test assez mature), rc (pré-version)
• La raison pour laquelle la version est incertaine
 : lors de l'exécution de l'installation par défaut de npm instruction de dépendance, npm pense que les développeurs suivront les spécifications de mise à niveau de la version semver et installeront directement la dernière version du package de dépendances pour le développeur

Solution 1 : vous pouvez désactiver le comportement par défaut consistant à utiliser ^ devant le numéro de version via la commande npm config set save-exact true

Résumé : Impossible de résoudre le problème des propres dépendances de la bibliothèque de dépendances en installant la dernière version mineure par défaut

• Option 2 résolue : npm fournit la commande Shrinkwrap, qui générera un

fichier pour enregistrer des versions précises de toutes les bibliothèques et de toutes les bibliothèques dépendantes imbriquées

• npm-shrinkwrap.jsonRésumé : le fichier de verrouillage ne sera pas généré par défaut et nécessite que l'utilisateur exécute manuellement les instructions en fonction des utilisateurs connaissent cette commande, qui est relativement lourde

  ;

• Phase 3 : Installation à plat

En 2015, afin de résoudre les problèmes d'installation imbriquée et de versions incohérentes de npm1 et npm2, le programme npm a été entièrement réécrit

Pronom :

Installation avec moins de dépendances redondantes, Répertoire node_modules aplati pour stocker les dépendances

Produits représentatifs : version npm v3

Brève description du principe : Lors de l'installation de npm, construisez d'abord l'arborescence des dépendances, puis installez toutes les dépendances dans le répertoire racine de node_modules. Lorsque les sous-dépendances rencontrent différentes versions de dépendances portant le même nom, les sous-dépendances seront. installés sous leurs propres node_modules

Principales caractéristiques :

(1) Réduire les installations redondantes : s'appuyer sur une installation à plat, qui réduit l'installation de packages redondants dans certaines circonstances

Problèmes existants :

(1) "Ghost dependency", "Phantom dependency" " Problème

(2) "Twin Strangers", "Dependency Package Clone" Problème

(3) Le répertoire n'est pas fixe : l'ordre d'installation des dépendances détermine la structure du répertoire node_module

Explication 1 : L'ordre d'installation des dépendances, La structure du répertoire node_modules est déterminée

Le scénario suivant :App1 dépend de packageA et packageC et packageG et packageH, et packageA et packageC dépendent tous deux de packageB v1.0, packageG et packageH les deux dépendent de la version du packageB v2.0

Si vous installez d'abord le packageA ou le packageC, le répertoire node_modules est le suivant

Si vous installez le packageG ou le packageH en premier, le répertoire node_modules est le suivant

En réponse à Dans la situation ci-dessus, npm fournit des instructionsnpm dedupe, vous pouvez organiser et simplifier manuellement la structure des répertoires de node_modules. Après le tri, la structure du répertoire node_modules est cohérente et n'est pas affectée par l'ordre d'installation des packages dépendants

Explication 2 : ce n'est pas nécessairement le cas. réduire l'installation de packages redondants

Par l'exemple 1, on peut voir que bien que les packages dépendants soient installés à plat, il existe toujours des packages de dépendances de la même version qui ont des packages redondants

Explication 3 : problème "Twin Strangers"

Reportez-vous à l'exemple 1, la même version des packages de dépendances est installée deux fois et placée à deux endroits. Ce phénomène est connu sous le nom de "Twin Strangers"

Explication 4 : Problème de "dépendance fantôme"

node_modules Packages de dépendances dans le premier. Le répertoire de niveau peut être utilisé directement par les développeurs, mais les packages de dépendances ne sont pas définis dans package.json, comme ceci. Les packages de dépendances sont appelés "dépendances fantômes". Si des "dépendances fantômes" sont utilisées dans les projets front-end, des problèmes peuvent survenir plus tard.

Étant donné que cette "dépendance fantôme" peut être supprimée en raison de la mise à niveau ultérieure d'autres dépendances, elle n'existera plus dans node_modules lors de l'exécution de npm install, la "dépendance fantôme" ne sera pas installée subjectivement, ce qui entraînera la non-installation du projet. trouvé. Accédez au package dépendant et signalez une erreur.

Phase 4 : Sécurité et accélération

En 2016, les versions de fil et de pnpm sont apparues l'une après l'autre, ce qui a dans une certaine mesure résolu les problèmes des versions d'installation précédentes tels que l'incertitude et la vitesse d'installation lente par rapport aux capacités. ce fil a été le premier à être lancé, npm, plus accrocheur, assure la cohérence et la sécurité et améliore la vitesse d'installation

Synonymes : L'installation dépendante est relativement sûre et accélère

Produits représentatifs : version de sortie du fil, pnpm version release, version npm v5 (npm v4 n'a pas beaucoup changé, la v5 a fait un grand pas en avant)

Principales caractéristiques :

(1) Sécurité : le fichier de verrouillage de version est généré par défaut, garantissant que la version de dépendance est le même à chaque fois que vous l'installez

(2) Accélération : ajout de l'installation hors ligne du cache, installation parallèle, nouvelle tentative automatique après exception d'installation

(3) espace de travail : le fil est pris en charge à partir de la version v1, qui peut gérer efficacement le les packages de dépendances de plusieurs projets ; npm v7 ne prend en charge que l'espace de travail

Problèmes  :

(1) Dépendances fantômes

(2) Les packages de dépendances sont installés à plusieurs reprises sur des projets uniques et sur plusieurs projets

(3) Le répertoire n'est pas corrigé : l'ordre d'installation des dépendances détermine la structure du répertoire node_module

Explication 1 : A propos de la sécurité

yarn v0.x prend la tête, suivi de près par npm v5.x Lors du téléchargement des dépendances, un fichier de verrouillage des dépendances est généré par défaut. , qui verrouille avec précision la version à une valeur

• fichier .lock de yarn : il enregistre uniquement la version de la dépendance installée. Il doit être combiné avec package.json pour déterminer la structure du répertoire node_modules
• npm : enregistre le. version de dépendance installée et structure de répertoire node_modules.

Résumé : Évite d'avoir à installer des dépendances sur différents terminaux. Problème d'incohérence de version, mais le problème du "fantôme de dépendance" existe toujours

Explication 2 : À propos de l'amélioration de la vitesse - mise en cache hors ligne.

La version npm v2 prend en charge la mise en cache, mais nécessite une détection en ligne pour utiliser les dépendances mises en cache

yarn v0.x Cette version est la première à prendre en charge la mise en cache hors ligne. Les packages téléchargés depuis Internet seront mis en cache globalement lors de la prochaine installation. recherchez d'abord localement. Si vous trouvez une copie, vous pouvez la copier directement. La version npm v5 a réécrit le système de cache et prend également en charge l'installation hors ligne

Explication 3 : Concernant l'accélération - installation parallèle.

yarn a été le premier à prendre en charge l'installation parallèle des packages de dépendances. Auparavant, npm installait les dépendances en série. Plus tard, npm optimisait également l'installation parallèle

Explication 4 : Après l'installation des dépendances, le répertoire node_modules est automatiquement organisé. Heure de début : version Yarn v1.x, version npm v4.x

• Si le fichier .lock est supprimé du projet, le répertoire node_modules sera automatiquement organisé lors de l'initialisation des dépendances ; pour les versions antérieures à npm v4.x, l'utilisateur doit exécuter manuellement la commande npm dédupe Organiser le répertoire des dépendances.lock 文件，初始化安装依赖时，会自动整理 node_modules 目录；npm v4.x之前版本，需要用户手动执行指令 npm dedupe整理依赖目录
• 由于 node_modules 是扁平化管理依赖，深层依赖可能会被安装到一级目录下；当项目中再安装不同版本的依赖时，遇到依赖版本冲突，会自动将深层依赖从一级目录移动到父依赖目录下 【已验证】

阶段五：更安全、高速、低耗

对着 pnpm 的成熟，开发者们享受着 pnpm 带来的 更安全、更高速、存储更低耗 等红利，解决了“幽灵依赖” 问题，解决了重复依赖问题

代名词： 安全（依赖安装所见即所得）、高速（不重复安装）、存储低耗（硬链接 + 软链接）

代表产物： pnpm

关键特点：

（1）速度极快：存储中心集中管理依赖，直接硬链接到项目的 node_modules/.pnpm

Étant donné que node_modules est une dépendance de gestion plate, des dépendances profondes peuvent être installées dans le répertoire de premier niveau lors de l'installation de différentes versions de dépendances dans le projet, en cas de conflit de version de dépendance ; rencontrées, les dépendances profondes seront automatiquement déplacées du répertoire de premier niveau vers le répertoire de premier niveau. Le répertoire est déplacé vers le répertoire de dépendances parent

【Vérifié】

Phase 5 : Plus sécurisé, plus rapide et moins coûteux

Face à la maturité de pnpm, les développeurs bénéficient des avantages d'une consommation de stockage plus sûre, plus rapide et plus faible apportée par pnpm, qui résout la « dépendance fantôme » problème et résout le problème des dépendances répétées

Pronom:

Sécurité (installation des dépendances WYSIWYG), haute vitesse (pas d'installation répétée), faible consommation de stockage (lien dur + lien logiciel)

Produit représentatif:

pnpm

Principales fonctionnalités :

(1) Extrêmement rapide

 : Le centre de stockage gère les dépendances de manière centralisée, lien direct vers le node_modules/.pnpm du projet. Par rapport à la méthode de travail précédente, un grand nombre d'opérations d'E/S depuis la copie globale des node_modules vers le projet sont réduits

(2) Utilisation extrêmement élevée du disque🎜 :🎜🎜🎜Partagez la même version des dépendances entre les projets : liens physiques, liens logiciels 🎜🎜Maximiser la réutilisation de différentes versions de la même dépendance : ajoutez uniquement des fichiers Diff pour stocker différentes versions🎜🎜🎜 (3) Haute sécurité : la structure du répertoire node_modules est la liste de dépendances package.json, résolvant le problème de la "dépendance fantôme" 🎜🎜 🎜🎜🎜🎜Les performances sont les suivantes : 🎜🎜🎜🎜🎜🎜Pour plus de connaissances sur les nœuds, veuillez visiter : 🎜tutoriel nodejs🎜 ! 🎜

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!