Ein Artikel über die fünf Phasen der Entwicklung der Knotenpaketverwaltung

Seit der Geburt von Node im Jahr 2009 hat sich das Node-Ökosystem weiterentwickelt und gediehen. Aus dem Node-Ökosystem abgeleitete Paketmanager sind npm, kpm, pnpm, Yarn, cnpm usw. erschienen. Tatsächlich ist die Entwicklung des Node-Paketmanagers hauptsächlich in 5 Phasen unterteilt. Werfen wir einen Blick auf die Hauptfunktionen und repräsentativen Produkte jeder Phase~

Phase 1: Slash and Burn

Um genau zu sein: Node existierte nicht ohne einen Paketmanager. Als Node.js 2009 herauskam, wurde auch der Prototyp von npm veröffentlicht. [Verwandte Tutorial-Empfehlungen: nodejs-Video-Tutorial, Programmierunterricht]

npm ist der vollständige Name von Node.js Package Manager; aus Eine kurze Geschichte von Node.js können Sie sehen

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

Lass uns darüber reden Knotenpaket, das nicht angezeigt wird Wie war es in der Manager-Ära? Was ich damals noch tat, war, online nach der offiziellen Website jeder Software zu suchen, z. B. nach der Download-Adresse und dem Herunterladen der Zip-Datei Paket;

• Entpacken Sie es und legen Sie es in einem Verzeichnis namens libs im Projekt ab.

• Wenn Sie es bequemer machen möchten, fügen Sie den CDN-Link direkt in das HTML ein.

• Modulare Verwaltung Zeit? Versionsnummernverwaltung? Auf ein Upgrade angewiesen? Keine davon existiert!

• Phase 2: Verschachtelte Installation

Im Jahr 2009 wurde Node.js geboren, und 2011 wurde auch der Prototyp von npm veröffentlicht; npm basiert auf der Idee der semantischen Versionskontrolle Semver, das von Entwicklern von Node-Paketen standardmäßig berücksichtigt wird, aktualisiert beim Upgrade der benutzerdefinierten Versionsnummer abhängiger Pakete die Versionsnummer gemäß der Semver-Spezifikation.

Synonyme:

Standardisierung der Knotenpaketverwaltung, verschachtelte Speicherung von Abhängigkeiten im Verzeichnis node_modules

Repräsentative Produkte:

npm v1, v2-Version

Hauptmerkmale:

(1) Verschachtelte Installation abhängiger Pakete derselben Version Abhängigkeiten werden redundant installiert (2) Unsicherheit bei der Installation des Abhängigkeitspakets: Die neueste Version des Abhängigkeitspakets wird standardmäßig installiert (feste Version kann festgelegt werden)

(3) Die serielle Installation von Abhängigkeiten ist langsam; Offline-Caching wird nicht unterstützt

Erklärung 1: Abhängigkeit

Verschachtelte Installation

Wenn A von B und B von C abhängt, lautet das Verzeichnis node_modules wie folgt:

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

Problem: Eine zu starke Verschachtelung von Abhängigkeiten führt zur Verschachtelungshölle, und Gleichzeitig wird es zu einer großen Anzahl redundanter Installationen derselben abhängigen Pakete kommen, die dazu führen, dass node_modules zu groß ist, sodass Programmierer regelmäßig rm -rf node_modules ausführen müssen. In Windows-Systemen können jedoch viele Programme Dateipfadnamen mit mehr als 260 nicht verarbeiten Zeichen. Dies wurde von frühen Windows-Benutzern von npm gesehen. Erklärung 2: Bei jeder npm-Installation wird standardmäßig die neueste Version der Abhängigkeiten installiert, was zu Unsicherheit bei der Installation von Abhängigkeiten führt Problem:

semver standardisiert die Zusammensetzung der Versionsnummer: alte Version, aktualisieren Sie die Hauptversionsnummer Y ist die Nebenversionsnummer: Neue API wurde hinzugefügt. Aus Gründen der Abwärtskompatibilität ist die Upgrade-Nebenversionsnummer

Z die Patch-Versionsnummer: Wenn die Reparatur des Abwärtskompatibilitätsfehlers abgeschlossen ist

Der Status kann sein: Alpha (interner Test), Beta (öffentlicher Test), Gamma (ziemlich ausgereifte Testversion), RC (Vorabversion)

---

Der Grund, warum die Version unsicher ist: Beim Ausführen der npm-Standardinstallation Abhängigkeitsanweisung: NPM geht davon aus, dass Entwickler die Semver-Versionsaktualisierungsspezifikationen befolgen und installiert direkt die neueste Version des Abhängigkeitspakets für den Entwickler Lösung 1: Sie können das Standardverhalten der Verwendung von ^ vor der Versionsnummer durch deaktivieren Der Befehl „npm config set save-exact true“

Zusammenfassung: Das Problem, dass die Abhängigkeiten der Abhängigkeitsbibliothek selbst die neueste Nebenversion standardmäßig installieren, konnte nicht gelöst werden

• Gelöst Option 2: npm stellt den Befehl „shrinkwrap“ bereit, der eine generiert
Datei zum Aufzeichnen genauer Versionen aller Bibliotheken und aller verschachtelten abhängigen Bibliotheken
• Zusammenfassung: Die Sperrdatei wird nicht standardmäßig generiert und erfordert, dass der Benutzer Anweisungen manuell ausführt. Benutzer kennen diesen Befehl, was relativ umständlich ist

Phase 3: Flache Installation

Um die Probleme der verschachtelten Installation und der inkonsistenten Versionen von npm1 und npm2 zu lösen, wurde das npm-Programm 2015 komplett neu geschrieben
• Pronomen:
Installation mit weniger redundanten Abhängigkeiten, Abgeflachtes Verzeichnis „node_modules“ zum Speichern von Abhängigkeiten

• Repräsentative Produkte:

  npm v3-Version npm-shrinkwrap.json

  Kurze Beschreibung des Prinzips: Erstellen Sie bei der Installation von npm zunächst den Abhängigkeitsbaum und installieren Sie dann alle Abhängigkeiten im Stammverzeichnis von node_modules. Wenn Unterabhängigkeiten auf unterschiedliche Versionen von Abhängigkeiten mit demselben Namen stoßen, werden die Unterabhängigkeiten angezeigt unter ihren eigenen node_modules installiert

  Hauptmerkmale:

  (1) Redundante Installation reduzieren: Verlassen Sie sich auf eine flache Installation, die unter bestimmten Umständen die Installation redundanter Pakete reduziert

  Bestehende Probleme:

  (1) „Ghost Abhängigkeit“, „Phantomabhängigkeit“ „ Problem

  (2) „Zwillingsfremde“ und „Abhängigkeitspaketklone“ Problem

  (3) Das Verzeichnis ist nicht festgelegt: Die Installationsreihenfolge der Abhängigkeiten bestimmt die Verzeichnisstruktur „node_module“

  Erklärung 1: Die Reihenfolge der Installation von Abhängigkeiten, die Verzeichnisstruktur node_modules wird bestimmt

  Das folgende Szenario:App1 hängt von PaketA und PaketC sowie PaketG und PaketH ab, und PaketA und PaketC hängen beide von PaketB v1.0, PaketG und PaketH ab beide hängen von der Version von packageB v2.0 ab

  Wenn Sie zuerst packageA oder packageC installieren, lautet das Verzeichnis node_modules wie folgt

  

  Wenn Sie zuerst packageG oder packageH installieren, lautet das Verzeichnis node_modules wie folgt

  

  Als Antwort auf In der oben genannten Situation bietet npm Anweisungen. Sie können die Verzeichnisstruktur von node_modules nach dem Sortieren manuell organisieren und vereinfachen. Die Verzeichnisstruktur von node_modules ist konsistent und wird von der Installationsreihenfolge abhängiger Pakete nicht beeinflusst. Erklärung 2: Dies ist möglicherweise nicht unbedingt der Fall Reduzieren Sie die Installation redundanter Paketenpm dedupe

  Anhand von Beispiel 1 ist ersichtlich, dass abhängige Pakete zwar flach installiert werden, es aber immer noch Abhängigkeitspakete derselben Version mit redundanten Paketen gibt

  Erklärung 3: „Twin Strangers“-Problem

  Siehe Beispiel 1, die gleiche Version von Abhängigkeitspaketen wird zweimal installiert und an zwei Orten platziert. Dieses Phänomen ist als „Twin Strangers“ bekannt.

  Erklärung 4: „Ghost Dependency“-Problem.

  node_modules Abhängigkeitspakete im ersten. Das Level-Verzeichnis kann von Entwicklern direkt verwendet werden, die Abhängigkeitspakete sind jedoch nicht in package.json definiert. Abhängigkeitspakete werden als „Ghost-Abhängigkeiten“ bezeichnet. Wenn in Front-End-Projekten „Ghost-Abhängigkeiten“ verwendet werden, kann es später zu Problemen kommen. Da diese „Geisterabhängigkeit“ aufgrund der späteren Aktualisierung anderer Abhängigkeiten möglicherweise entfernt wird, ist sie in node_modules nicht mehr vorhanden. Bei der Ausführung von npm install wird die „Geisterabhängigkeit“ subjektiv nicht installiert, was dazu führt, dass das Projekt nicht mehr vorhanden ist gefunden. Gehen Sie zum abhängigen Paket und melden Sie einen Fehler.

  Phase 4: Sicherheit und Beschleunigung

  Im Jahr 2016 erschienen nacheinander die Release-Versionen von Yarn und PNPM, wodurch die Probleme früherer Installationsversionen wie Unsicherheit und langsame Installationsgeschwindigkeit im Vergleich zu den Funktionen bis zu einem gewissen Grad gelöst wurden Dieses Garn war das erste, das auf den Markt kam, npm, auffälliger, sorgt für Konsistenz und Sicherheit und verbessert die Installationsgeschwindigkeit

  Synonyme:

  Die abhängige Installation ist relativ sicher und beschleunigt

  Repräsentative Produkte: Garnfreigabeversion, pnpm Release-Version, npm v5-Version (npm v4 hat sich nicht viel geändert, v5 hat einen großen Schritt nach vorne gemacht)

  Hauptmerkmale:

  (1) Sicherheit: Die Versionssperrdatei wird standardmäßig generiert, um sicherzustellen, dass die Abhängigkeitsversion ist bei jeder Installation gleich Abhängigkeitspakete mehrerer Projekte; npm v7 unterstützt nur die Existenz von Arbeitsbereichen

  Probleme

  :

  (1) Ghost-Abhängigkeiten

  (2) Abhängigkeitspakete werden wiederholt auf einzelnen Projekten und projektübergreifend installiert

  (3) Das Verzeichnis ist nicht festgelegt: Die Installationsreihenfolge der Abhängigkeiten bestimmt die Verzeichnisstruktur „node_module“

  Erklärung 1: Über Sicherheit

  yarn v0.x übernimmt die Führung, dicht gefolgt von npm v5.x. Beim Herunterladen von Abhängigkeiten ist eine Abhängigkeitssperrdatei vorhanden Wird standardmäßig generiert, wodurch die Version genau auf einen Wert der .lock-Datei von

  yarn gesperrt wird: Sie muss nur mit package.json kombiniert werden, um die Verzeichnisstruktur von node_modules zu bestimmen : Zeichnet die installierte Abhängigkeitsversion und die Verzeichnisstruktur „node_modules“ auf.
  Zusammenfassung:

  Vermeidet die Notwendigkeit, Abhängigkeiten auf verschiedenen Terminals zu installieren, aber das „Abhängigkeitsgeist“-Problem besteht weiterhin.

  • Erläuterung 2: Informationen zur Geschwindigkeitsverbesserung - Offline-Caching
  • npm v2-Version unterstützt Caching, erfordert jedoch eine Online-Erkennung, um zwischengespeicherte Abhängigkeiten zu verwenden.

  yarn v0.x Diese Version ist die erste, die Offline-Caching unterstützt. Aus dem Internet heruntergeladene Pakete werden bei der nächsten Installation global zwischengespeichert Wenn Sie eine Kopie finden, können Sie diese direkt kopieren. Die npm v5-Version hat das Cache-System neu geschrieben und unterstützt auch die Offline-Installation. Erläuterung 3: Bezüglich der Geschwindigkeit - Parallele Installation

  yarn war das erste Unternehmen, das die parallele Installation von Abhängigkeitspaketen unterstützte. Später hat npm auch die parallele Installation optimiert

  Erläuterung 4: Nach der Installation von Abhängigkeiten wird das Verzeichnis node_modules automatisch organisiert.

  Startzeit: Garn v1.x-Version, npm v4.x-Version
  • Wenn die Datei .lock aus dem Projekt gelöscht wird, wird das Verzeichnis node_modules beim Initialisieren der Abhängigkeiten automatisch organisiert; für Versionen vor npm v4.x muss der Benutzer den Befehl npm dedupe Organisieren Sie das Abhängigkeitsverzeichnis.lock 文件，初始化安装依赖时，会自动整理 node_modules 目录；npm v4.x之前版本，需要用户手动执行指令 npm dedupe整理依赖目录
  • 由于 node_modules 是扁平化管理依赖，深层依赖可能会被安装到一级目录下；当项目中再安装不同版本的依赖时，遇到依赖版本冲突，会自动将深层依赖从一级目录移动到父依赖目录下 【已验证】

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

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

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

  代表产物： pnpm

  关键特点：

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

  Da es sich bei node_modules um eine flache Verwaltungsabhängigkeit handelt, können tiefe Abhängigkeiten im Verzeichnis der ersten Ebene installiert werden, wenn ein Abhängigkeitsversionskonflikt besteht Wenn festgestellt wird, werden die tiefen Abhängigkeiten automatisch vom Verzeichnis der ersten Ebene in das Verzeichnis der übergeordneten Abhängigkeiten verschoben.

  【Verifiziert】

  Phase 5: Sicherer, schneller, kostengünstiger
  • Angesichts der Reife von pnpm genießen Entwickler die Vorteile eines sichereren, schnelleren und geringeren Speicherverbrauchs durch pnpm, wodurch die „Geisterabhängigkeit“ gelöst wird. Problem und löst das Problem wiederholter Abhängigkeiten Hauptmerkmale:

  (1) Extrem schnell

  : Storage Center verwaltet Abhängigkeiten zentral, direkter fester Link zum node_modules/.pnpm des Projekts. Im Vergleich zur vorherigen Arbeitsmethode wird eine große Anzahl von E/A-Vorgängen vom Kopieren globaler node_modules in das Projekt reduziert. Softlinks

  Maximieren Sie die Wiederverwendung verschiedener Versionen derselben Abhängigkeit: Fügen Sie nur Diff-Dateien hinzu, um verschiedene Versionen zu speichern

  (3) Hohe Sicherheit: Die Verzeichnisstruktur node_modules ist die Abhängigkeitsliste package.json, wodurch die „Geisterabhängigkeit“ gelöst wird. Problem

  

  Die Leistung ist wie folgt:

  🎜🎜🎜Weitere Informationen zu Knoten finden Sie unter: 🎜nodejs-Tutorial🎜! 🎜

Das obige ist der detaillierte Inhalt vonEin Artikel über die fünf Phasen der Entwicklung der Knotenpaketverwaltung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!