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

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

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

• 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

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

• 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

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

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

• 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

【Vérifié】

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