Detaillierte Einführung in den Modulinstallationsmechanismus von npm-js-Tutorial-php.cn

Die logische Struktur der Abhängigkeitsbaumoberfläche und die tatsächliche physische Struktur des Abhängigkeitsbaums

Die Oberfläche des Abhängigkeitsbaums Die logische Struktur stimmt nicht unbedingt mit der tatsächlichen physischen Struktur des Abhängigkeitsbaums überein!

Zwei Befehle sollten zuerst erwähnt werden: tree -d (Linux) und npm ls (npm)

Unter einem npm-Projekt:

tree -d BefehlListet die physischen Strukturen aller Abhängigkeiten unter einem Projekt in einem Baumdiagramm auf

npm ls-BefehlListet die logische Struktur aller Abhängigkeiten unter einem Projekt in einem Baumdiagramm auf

Nehmen Sie das offizielle Dokument als Beispiel:

Projektbeispiel1 hat zwei abhängige Module: Mod-A-Modul und Mod-C-Modul; >mod-a-Modul hat ein abhängiges Modul mod-b@1.0.0-Modul

mod-c-Modul hat ein abhängiges Modul mod-b@2.0.0 Die Ergebnisse von Modul

tree -d und npm ls lauten wie folgt: (Beachten Sie, dass die npm-Version npm3 statt npm2 ist)

Sehen Sie sich zunächst das Ergebnis im roten Feld unten an. Dies sollte das konsistenteste Ergebnis von Wir verstehen den Abhängigkeitsbaum von „

. Zuerst wird die Abhängigkeit der ersten Ebene unter dem Projekt gebildet – Mod-a-Modul und Mod-b-Modul. Dann werden diese beiden Module als übergeordnete Module und die zweite Ebene verwendet Abhängigkeitsmodul mod-b@1.0 wurde hinzugefügt .0 und mod-b@2.0.0

Aber! So sieht der physisch geformte Abhängigkeitsbaum nicht aus. Der physisch geformte Abhängigkeitsbaum ist das rote Kästchen oben. mod-a, mod-c und mod-b sind tatsächlich Abhängigkeiten derselben Ebene

Sie fragen sich vielleicht: Warum wird ein solcher Abhängigkeitsbaum gebildet? Lassen Sie es mich unten erklären

[Hinweis]: Bei den folgenden Abbildungen handelt es sich ausschließlich um physische Strukturen von Abhängigkeitsbäumen logische Struktur

Eine kleine Vermutung über den Installationsmechanismus des npm-Moduls

Bei der Installation eines Moduls gibt es zwei Möglichkeiten: horizontale Installation oder

verschachtelte

Installation (hier sind nur Vermutungen und Annahmen)

Kann die Installationsmethode vollständig horizontal sein? ——

Kann nicht

Nehmen wir ein ähnliches Beispiel wie oben: Es gibt zwei abhängige Module A und B unter dem Projekt APP. A hat ein abhängiges Modul Cv1.0 und B hat auch ein abhängiges Modul Cv2.0. Offensichtlich können sie nicht gleichzeitig unter denselben Knotenmodulen vorhanden sein. Aufgrund des Mechanismus von npm kann nur eine Version des abhängigen Moduls installiert werden. Eine davon überschreibt die andere.

Aber wenn wir nur eine Version des C-abhängigen Moduls installieren, kann dies dazu führen, dass Modul A und B-Modul ist nicht kompatibel

Basierend auf den oben genannten Gründen, npm2 wählte die verschachtelte Installationsmethode –

Modulinstallationsmechanismus unter npm2

npm2 installiert mehrstufige Abhängigkeitsmodule mithilfe einer verschachtelten Installationsmethode:

Vor- und Nachteile

Vorteile: Die Einzelversion wurde gelöst Erreichen Sie Kompatibilität mit mehreren Versionen

Nachteile: kann eine große Redundanz desselben Moduls verursachen ist wie folgt folgt:

Am Beispiel des obigen Beispiels ist auch die folgende Situation sinnvoll:

Ich weiß aus eigener Erfahrung, dass dies keineswegs ein gutes Phänomen ist. Wie können wir also diese Art von Modulredundanz reduzieren und gleichzeitig eine Multiversionskompatibilität zwischen Abhängigkeiten erreichen? Also hat npm3 einige Verbesserungen vorgenommen

Der Modulinstallationsmechanismus unter npm3:

Der Unterschied zwischen npm3 und npm2 spiegelt sich hauptsächlich in der Installation sekundärer Module wider:

npm3 wird „versuchen“ Logischerweise werden Module auf einer bestimmten Ebene hinsichtlich der physischen Struktur auf der ersten Ebene des Projekts platziert „Alle“

1 . Wenn Sie bei der Installation eines bestimmten Moduls der zweiten Ebene feststellen, dass es auf der ersten Ebene

kein Modul mit demselben Namen gibt , geben Sie dies ein Modul der zweiten Ebene auf der ersten Ebene 2. Während der Installation Wenn ein Modul der zweiten Ebene gefunden wird, wenn die erste Ebene wird festgestellt, dass es denselben Namen und dieselbe Version des Moduls hat

, dann dieses Modul direkt wiederverwenden 3 Bestimmtes Modul der zweiten Ebene, wenn die erste Ebene gefunden wird hat denselben Namen, aber unterschiedliche Versionen von Modulen , sodass

nur darunter verschachtelt werden kann eigenes übergeordnetes Modul

Das mag zunächst etwas schwer zu verstehen sein, also schauen wir uns die Bilder an und lassen Sie uns reden!

Lassen Sie mich mit 1 beginnen: Wenn Sie ein Modul der zweiten Ebene installieren, wenn Sie feststellen, dass das erste -Level-Modul wurde nicht verwendet. Für Module mit demselben Namen platzieren Sie dieses Modul der zweiten Ebene auf der ersten Ebene

Vereinfachen wir zunächst das obige Beispiel: Jetzt da ist nur eines unter dem Projekt APP Das Abhängigkeitsmodul A der ersten Ebene verfügt über ein Abhängigkeitsmodul C der zweiten Ebene, aber bei der Installation von npm wird die Abhängigkeit unter dem Projekt

Das Modul der zweiten Ebene (C v1.0) in npm3, wenn im Verzeichnis der ersten Ebene (node_modules) des Projekts kein Modul mit demselben Namen vorhanden ist, wird im Verzeichnis der ersten Ebene installiert und folgt somit dem übergeordneten Modul A derselben Ebene. Aus diesem Grund sind die logische Struktur und die physische Struktur des Abhängigkeitsbaums am Anfang dieses Artikels unterschiedlich .

Mit anderen Worten:

In npm2, The Die logische Struktur des Abhängigkeitsbaums ist dieselbe wie seine physische Struktur.

In npm3 ist die logische Struktur des Abhängigkeitsbaums dieselbe als seine physikalische Struktur. Anders

Weitere 2: Bei der Installation eines bestimmten Sekundärmoduls, wenn das erste Für Module mit demselben Namen und derselben Version auf der Ebene können wir dieses Modul direkt wiederverwenden

Auf Auf der Grundlage von 1 stellen wir das vorherige, kompliziertere Szenario wieder her: Es gibt zwei abhängige Module A und B unter dem Projekt APP. A hat ein abhängiges Modul Cv1.0 und B hat auch ein abhängiges Modul C v1 .0 (zwei C Die Modulversion ist gleich)

Für npm2 sind die beiden C-Pakete sind gleich, was zu Modulredundanz führt.

Da in npm3 Modul C unter Modul A auf der ersten Ebene installiert ist, kann Modul B auf derselben Ebene wiederverwendet werden. und der Name, die Version, alle die gleichen C-Module

npm3 verwendet diese Methode, um die Schwachstellen (teilweise) von npm2 teilweise zu lösen

[Übergang von 1, 2 zu 3] Ich habe am Anfang dieses Abschnitts gesagt: „npm3 wird es logischerweise „versuchen“. „Alle“ Level-Module werden in der ersten Ebene des Projekts platziert“, Ich denke, Sie sollten etwas verstehen, nachdem Sie 1 und 2 gelesen haben „Geben Sie Ihr Bestes“ Ja, aber Ich sagte „Versuchen Sie Ihr Bestes“ , was auch bedeutet, dass npm3 keine Abhängigkeiten der zweiten Ebene auf der ersten Ebene platzieren kann . Siehe dazu bitte 3:

Schließlich 3: Bei der Installation eines bestimmten Sekundärmoduls, wenn die zweiten Module mit Der gleiche Name, aber unterschiedliche Versionen auf einer Ebene können nur unterhalb ihres eigenen übergeordneten Moduls verschachtelt werden

In 2 sind die beiden C-Module, von denen A und B abhängen, gleich. Aber was ist, wenn die Versionen der beiden C-Module unterschiedlich sind? , die Projekt-npm-Installationssituation ist wie folgt:

in npm3, weil B und A require Die abhängigen Module sind unterschiedlich (die Anforderung unter B ist C von v1.0 und die Anforderung unter A ist C von v2.0), sodass B das C v1.0-Modul unter A nicht wie in 2

(Wenn ich das sehe, denke ich, dass es Ihre Zweifel an dem Beispiel am Anfang des Artikels ausräumen sollte. Dieses Beispiel ist fast genau das gleiche wie dieses Beispiel)

Wenn Sie dies sehen, haben Sie ein allgemeines Verständnis des Modularbeitsmechanismus unter npm2 und npm3 sowie der Optimierung von npm3 für npm2, aber bitte Denken Sie über diese Frage nach: Hat npm3 die Modulredundanzfehler von npm2 bis zum Äußersten optimiert? ———Die Antwort ist Nein , bitte lesen Sie unten:

Eigentlich: Modulredundanz kann in npm3 immer noch auftreten, da sich im Verzeichnis der ersten Ebene bereits ein v1.0-C-Modul befindet, Also Alle v2.0 können nur als sekundäre Abhängigkeitsmodule installiert werden, sodass Sie die folgende Situation sehen werden

Und im oben gezeigten Sonderfall scheint es keinen Unterschied zwischen npm3 und npm2 zu geben

【Übergang】Gibt es eine Lösung dafür? Natürlich gibt es das. Wenn das C v1.0-Modul unter A-Modul auf C v2.0 aktualisiert wird, können wir alle C v2.0-sekundär abhängigen Module durch npm-Deduplizierung auf C v2.0 „umleiten“. .0 im Verzeichnis der ersten Ebene

Verwenden Sie npm dedupe, um redundante Module zu entfernen:

Was hat die NPM-Deduplizierung bewirkt? Es kann alle redundanten abhängigen Module der zweiten Ebene, die entfernt werden können, zu Modulen der ersten Ebene mit dem gleichen Namen/der gleichen Version „umleiten“

Referenzen npm offizielles Dokument Abschnitt 2 (wie npm funktioniert):

[Warme Erinnerung]: Kein beliebter Blog kann mit einem schweren Buch und einem langweiligen Dokument mithalten

【Ende】

Merken Sie sich jeden Tag 10 kleine Wörter, das Wichtigste ist: Ansammeln!

Speicher: Speicherabhängigkeit: Abhängigkeitseinschränkungen: Einschränkungen Bereitstellung: Bereitstellungsparameter: Parameterbereich: Bereich

Ökosysteme: Ökosystempräfix: Präfix Prior: Priorität/bevor widerrufen: widerrufen

Das obige ist der detaillierte Inhalt vonDetaillierte Einführung in den Modulinstallationsmechanismus von npm. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!