Introduction détaillée au mécanisme d'installation des modules de npm-js tutoriel-php.cn

La structure logique de la surface de l'arbre de dépendances et la structure physique réelle de l'arbre de dépendances

La surface de l'arbre de dépendances La structure logique n'est pas nécessairement la même que la structure physique réelle de l'arbre de dépendances !

Deux commandes doivent être mentionnées en premier : tree -d (linux) et npm ls (npm)

Sous un projet npm :

commande tree -dRépertorie les structures physiques de toutes les dépendances d'un projet dans un diagramme arborescent

Commande npm lsRépertorie la structure logique de toutes les dépendances sous un projet dans un diagramme arborescent

Prenons l'exemple du document officiel :

L'exemple de projet 1 a deux modules dépendants : le module mod-a et le module mod-c

Le module mod-a a un module dépendant mod-b@1.0.0 module

Le module mod-c a un module dépendant mod-b@2.0.0 Les résultats du module

tree -d et npm ls sont les suivants : (notez que la version npm est npm3 au lieu de npm2)

Regardez d'abord le résultat de la case rouge ci-dessous. Cela devrait être le résultat le plus cohérent pour <.> Nous comprenons l'arbre de dépendances de ". Tout d'abord, la dépendance de premier niveau est formée sous le projet - module mod-a et module mod-b. Ensuite, ces deux modules sont utilisés comme modules parents et le module de deuxième niveau le module de dépendances mod-b@1.0 est ajouté .0 et mod-b@2.0.0

Mais !

Ce n'est pas à quoi ressemble l'arbre de dépendances physiquement formé. L'arbre de dépendances physiquement formé est la boîte rouge ci-dessus. mod-a, mod-c et mod-b sont en fait des dépendances du même niveau .

Vous vous demandez peut-être :

Pourquoi un tel arbre de dépendances est-il formé ? Laissez-moi vous expliquer ci-dessous

[Remarque] : Les illustrations suivantes sont toutes des structures physiques d'arbres de dépendances plutôt qu'un arbre de dépendance. structure logique

Une petite supposition sur le mécanisme d'installation du module npm

Lors de l'installation d'un module, il existe deux manières possibles :

Installation horizontale ou Installation imbriquée (voici juste des conjectures et hypothèses)

La méthode d'installation peut-elle être complètement horizontale ? ——

Impossible

Prenons un exemple similaire à celui ci-dessus : il y a deux modules dépendants A et B sous le projet APP ; A a un module dépendant Cv1.0 et B a également un module dépendant Cv2.0 ; Évidemment, ils ne peuvent pas exister sous les mêmes node_modules en même temps. Lors de l'installation, en raison du mécanisme de npm, une seule version du module dépendant peut être installée, l'une d'elles écrasera l'autre.

Mais si nous installons seulement une version du module dépendant du C, cela peut donner lieu au module A et Le module B n'est pas compatible

Pour les raisons ci-dessus, npm2 a choisi la méthode d'installation imbriquée -

Mécanisme d'installation du module sous npm2

npm2 installe des modules de dépendances à plusieurs niveaux en utilisant une méthode d'installation imbriquée :

Avantages et inconvénients

Avantages : Résolu la version unique Atteindre la compatibilité multi-versions

Inconvénients : peut provoquer une grande redondance du même module est le suivant suit :

En prenant l'exemple ci-dessus comme exemple, la situation suivante est également raisonnable :

Je sais par sentiment que ce n'est en aucun cas un bon phénomène, alors comment pouvons-nous réduire ce type de redondance de modules tout en obtenant une compatibilité multi-version entre les dépendances ? Npm3 a donc apporté quelques améliorations

Le mécanisme d'installation du module sous npm3 :

La différence entre npm3 et npm2 se reflète principalement dans l'installation des modules secondaires :

npm3 "essaiera de" Logiquement, les modules d'un certain niveau sont placés au premier niveau du projet en termes de structure physique "Tous"

1. . Lors de l'installation d'un certain module de deuxième niveau, si le premier niveau

Il n'y a pas de module du même nom , alors mettez ce module de deuxième niveau. au premier niveau 2. Lors de l'installation Lorsqu'un module de deuxième niveau est trouvé, si le premier niveau est trouvé avoir le même nom et la même version du module

, puis directement Réutiliser ce module Lors de l'installation d'une certaine seconde- module de niveau, si le premier niveau est trouvé a le même nom mais des versions différentes de modules , donc

ne peut être imbriqué que sous son propre module parent

Cela peut être un peu difficile à comprendre au début, alors regardons les photos et parlons !

Permettez-moi de commencer par 1 : lors de l'installation d'un certain module de deuxième niveau, si vous constatez que le le module de premier niveau n'a pas été Pour les modules du même nom, placez ce module de deuxième niveau au premier niveau

Simplifions d'abord l'exemple ci-dessus : maintenant il n'y en a qu'un sous le projet APP Le module dépendant de premier niveau A a un module dépendant de deuxième niveau C en dessous, mais lors de l'installation de npm, le module dépendant

Le module de deuxième niveau (C v1.0) dans npm3, lorsqu'il n'y a pas de module du même nom dans le répertoire de premier niveau (node_modules) du projet, sera installé dans le répertoire de premier niveau, suivant ainsi son module parent A Même niveau. C'est la raison pour laquelle la structure logique et la structure physique de l'arbre de dépendances au début de cet article sont différentes .

En d'autres termes :

Dans npm2, Le la structure logique de l'arbre de dépendances est la même que sa structure physique

Dans npm3, la structure logique de l'arbre de dépendances est la même comme sa structure physique. Différent

Autre 2 : Lors de l'installation d'un certain module secondaire, si le premier Pour les modules du même nom et de même version au niveau, on peut directement réutiliser ce module

Sur sur la base de 1, nous rétablissons l'exemple de 1 au scénario précédent plus compliqué : il y a deux modules dépendants A et B sous le projet APP ; A a un module dépendant Cv1.0 et B a également un module dépendant C v1 ; .0 (deux C La version du module est la même)

Pour npm2, les deux Les packages C sont les mêmes, provoquant la redondance du module

Dans npm3, car le module C sous le module A est installé au premier niveau, cela permet au module B d'être réutilisé au même niveau ; et le nom, la version, Tous les mêmes modules C

npm3 utilise cette méthode pour résoudre partiellement les points douloureux (partiellement) de npm2

[Transition de 1, 2 à 3] J'ai dit au début de cette section : "npm3 fera de son mieux" logiquement "Tous" les modules de niveau sont placés dans le premier niveau du projet", Je pense que vous devriez comprendre un peu après avoir lu 1 et 2 "faites de votre mieux" Oui , mais j'ai dit "faites de votre mieux" , ce qui signifie également que npm3 ne peut pas placer de dépendances de deuxième niveau sur le premier niveau . Pour cela, veuillez consulter 3 :

Enfin, 3 : Lors de l'installation d'un certain module secondaire, si le deuxième module avec le même nom mais des versions différentes à un même niveau ne peuvent être imbriquées que sous leur propre module parent

En 2, les deux modules C dont dépendent A et B sont les mêmes, Mais que se passe-t-il si les versions des deux modules C sont différentes ? , la situation d'installation du projet npm est la suivante :

dans npm3, car B et A require Les modules dépendants sont différents (l'exigence sous B est C de la v1.0, et l'exigence sous A est C de la v2.0), donc B ne peut pas réutiliser le module C v1.0 sous A comme dans 2

(Voyant cela, je pense que cela devrait répondre à vos doutes sur l'exemple du début de l'article. Cet exemple est presque exactement le même que cet exemple)

En voyant cela, vous avez une compréhension générale du mécanisme de fonctionnement des modules sous npm2 et npm3, ainsi que de l'optimisation de npm3 pour npm2, mais s'il vous plaît réfléchissez à cette Question : npm3 a-t-il optimisé à l'extrême les défauts de redondance des modules de npm2 ? ———La réponse est Non , veuillez lire ci-dessous :

En fait : La redondance des modules peut encore se produire dans npm3, car il y a déjà un module C v1.0 dans le répertoire de premier niveau, Donc toutes les v2.0 ne peuvent être installées qu'en tant que modules de dépendance secondaires, vous verrez donc la situation suivante

Et dans le cas particulier montré dans l'image ci-dessus, il ne semble y avoir aucune différence entre npm3 et npm2

【Transition】Alors, y a-t-il une solution à cela ? Bien sûr, lorsque le module C v1.0 sous le module A est mis à jour vers C v2.0, nous pouvons "rediriger" tous les modules dépendants secondaires C v2.0 vers C v2.0 via la déduplication npm du C v1. .0 dans le répertoire de premier niveau

Utilisez la déduplication npm pour supprimer les modules redondants :

Qu'a fait la déduplication npm ? Il peut "rediriger" tous les modules dépendants redondants de deuxième niveau qui peuvent être supprimés vers des modules de premier niveau portant le même nom/version