Nachdruck unter: https://zhuanlan.zhihu.com/p/53652105
Wissen Sie, wie wichtig die Versionsverwaltung von npm-Paketen ist?
Daisy
Daisy
Vorwort
Ich habe eine Tasse Starbucks getrunken und konnte nicht schlafen die ganze Nacht. Endlich habe ich Zeit, einen Artikel zu schreiben.
Mir mangelte es zuvor an Kenntnissen über die Paketversionsverwaltung, sodass ich bei bestimmten Anforderungen des Projekts in viele Schwierigkeiten geriet. Dieser Artikel soll Ihnen dabei helfen, die durch eine schlechte Paketversionsverwaltung verursachten Probleme zu vermeiden.
Hier ist Storytime:
Story 1
Unser Projekt verwendet die Bibliotheken preact und preact-compat. Eines Tages musste Little A Anforderungen stellen und war unter Zeitdruck. Deshalb wollte er einige Bibliotheken referenzieren, um die Effizienz zu verbessern. Allerdings war die aktuelle Preact-Compat zu niedrig und inkompatibel. was zu tun? Muss man überhaupt fragen? Aktualisieren Sie natürlich die Version von preact-compat.
Little A aktualisierte fröhlich das lokale Preact-Compat und führte es lokal aus. Es war normal, also wechselte er zur Remote-Version und veröffentlichte sie fröhlich.
Kurz nach der Veröffentlichung kam der Produktmanager zu Little B und sagte, was los sei, unsere Seite könne nicht verwendet werden! Sobald es auftaucht, ist es eine Maske, und ich kann sie nicht einmal ausschalten. Also fand Klein B schnell Klein A, der die Anforderung veröffentlichte und fragte, ob seine Datei geändert worden sei. Gleichzeitig wird auch der neueste Code für das lokale Debugging abgerufen. Das Problem wurde schnell gefunden – eine JSX-if-Bibliothek war aufgrund eines Preact-Compat-Versions-Upgrades inkompatibel. Wo es notwendig war, die Wenn-sonst-Logik zu beurteilen, scheiterte plötzlich alles.
Diese Geschichte sagt uns: Denken Sie nicht, dass das Aktualisieren der Version eine triviale Angelegenheit ist, insbesondere der Basisbibliothek. Jede Version, die Sie aktualisieren, kann auf anderen Seiten Probleme verursachen. Wenn ein Upgrade der Basisbibliothek erforderlich ist, stellen Sie daher sicher, dass alle Seiten, die diese Basisbibliothek verwenden, normal ausgeführt werden.
Story 2
Für ein bestimmtes Projektteam sah die vorherige package.json-Datei so aus:
"react": "^15.2.1",
"react-dom": "^15.2.1",
"react-redux": "^5.0.5",
"react-router-dom": "^4.1.2",
"react-router-redux": "^5.0.0-alpha.6",
"redux": "^3.5.2",
"rimraf": "^2.5.4",
"sass-loader": "^6.0.6",
"style-loader": "^0.18.2",
"webpack": "^3.4.1",
"webpack-dev-middleware": "^1.6.1",
"webpack-hot-middleware": "^2.12.2"
Scheint kein Problem zu sein, jeder schreibt so. Aber eines Tages stellte Xiao A beim Schreiben von Code fest, dass er lokal ausgeführt werden konnte, und stellte ihn daher gerne auf dem Serversystem bereit. Als er die Vorabversionsumgebung überprüfte, stellte er fest, dass etwas nicht stimmte? ! Es gibt eine Funktion auf der Seite, die nicht verwendet werden kann, aber lokal ist sie offensichtlich in Ordnung? So gebrochen.
Trinken Sie kaltes (oder heißes) Wasser, um sich abzukühlen.
Hier sind die Lösungen:
1. Wenn es kein Problem mit der lokalen Datei gibt, vergleichen Sie den Hashwert der auf dem Bereitstellungssystem generierten Datei mit dem lokalen.
2. Nach dem Vergleich habe ich festgestellt, dass sie wirklich unterschiedlich sind. Warum unterscheiden sich die lokale Umgebung und die vom Bereitstellungssystem erstellten Dateien?
3. Es muss sein, dass die lokale Umgebung und die Abhängigkeitsbibliothek des Bereitstellungssystems unterschiedlich sind, da der Geschäftscode absolut gleich ist.
Little A verglich dann die package.json auf dem lokalen und dem Bereitstellungssystem. Nichts besonderes.
Eigentlich sehen sie alle so aus:
"react": "^15.2.1",
"react-dom": "^15.2.1",
"react-redux": "^5.0.5",
"react-router-dom": "^4.1.2",
"react-router-redux": "^5.0.0-alpha.6",
"redux": "^3.5.2",
"rimraf": "^2.5.4",
"sass-loader": "^6.0.6",
"style-loader": "^0.18.2",
"webpack": "^3.4.1",
"webpack-dev-middleware": "^1.6.1",
"webpack-hot-middleware": "^2.12.2"
Aber wissen Sie, was das ^ vor der Paketversion in package.json bedeutet?
Das Folgende sind drei Minuten populärwissenschaftlicher Zeit:
Paketversionen können auf drei Arten geschrieben werden:
„react“: „15.2.1“ – stimmt nur mit einer Version überein, die eine gesperrte Version darstellt. Es wird nur die Version 15.2.1 heruntergeladen
„react“: „~15.2 .1 ” – Entspricht der neuesten Nebenversion des Abhängigkeitspakets. Beispielsweise entspricht ~15.2.1 allen 15.2.x-Versionen, schließt jedoch nicht 15.3.0 oder höher ein, d. h. >= 15.2.1 & & < 15.3.0 Also habe ich den Befehl npm ls --deep 0 auf den Computern von Little A und Little B ausgeführt, um zu sehen, welche Version des Abhängigkeitspakets schließlich installiert wurde. Daher werden alle Bibliotheken in unserem Projekt ab paketverwaltet ^, was eigentlich sehr riskant ist. . Denn später stellte sich heraus, dass sich Little B genauso verhielt wie das Bereitstellungssystem und Fehler meldete.
„react“: „^15.2.1“ – stimmt mit dem neuesten Hauptversions-Abhängigkeitspaket überein. Beispielsweise stimmt ^15.2.1 mit allen 15.x.x-Versionen überein , einschließlich 15.3.0, aber nicht 16.0.0, d. h. >=15.2.1 && < 16.0.0
(Tut mir leid, ich habe den Computer von Little B nicht. Little B hat [email protected] installiert. Alles andere ist gleich, nehmen wir an)
Es stellte sich heraus, dass es so war Wirklich anders. Es lag an Redux. Verursacht durch unterschiedliche Versionen.
Nachdem ich das Problem gefunden hatte, stellte ich fest, wie gefährlich es ist, ^ im Projekt zu verwenden, ohne die Version zu sperren. Aufgrund unterschiedlicher Umgebungen und unterschiedlicher Zeiten ist es leicht, unterschiedliche Versionen abhängiger Pakete zu installieren.
Lösung
Da dies durch Versionsinkonsistenz verursacht wird, müssen wir alle Abhängigkeitspakete des Projekts auf eine feste Version sperren. Zwingen Sie alle, genau dieselbe Version der Abhängigkeiten zu installieren.
Derzeit gibt es zwei Möglichkeiten:
- Schreiben Sie die Versionsnummer direkt, fügen Sie nicht das Präfix ~ hinzu, ^
ist unsere erste Schreibweise: „react“: „15.2.1“. Aber das ist so schwer aufrechtzuerhalten. Man muss immer im Auge behalten, welche Version der Beamte veröffentlicht hat und welche Probleme behoben wurden. Man muss sich auf Arbeitskräfte verlassen, um die Version zu warten und zu ändern. (Jedenfalls haben wir nicht die Arbeitskräfte dafür, also werden wir diesen Plan sofort aufgeben)
2. Verwenden Sie package-lock.json (npm 5.0.0+ wird mitgeliefert)
Ich weiß nicht, ob Ihnen aufgefallen ist, dass jedes Mal, wenn wir npm i ausführen, unser Das Projekt generiert automatisch einen Ordner package-lock.json. Die offizielle Erklärung lautet wie folgt.
Einfach ausgedrückt zeichnet diese package-lock.json die spezifische Version der Bibliothek auf, die installiert ist, wenn Sie aktuell npm i ausführen. Nun, werfen wir einen Blick darauf:
Oh mein Gott ~~~ Ich möchte nicht zu detailliert sein, sogar die Version der Bibliothek, von der dieses Paket abhängt, ist klar geschrieben. Einfach so.
Wir müssen diese Datei nur an das Bereitstellungssystem senden, und das Bereitstellungssystem installiert die abhängigen Pakete entsprechend der in package-lock.json angegebenen Paketversion.
Dadurch wird sichergestellt, dass Ihre lokalen Systeme und Bereitstellungssysteme sowie die Abhängigkeiten anderer Entwicklungsstudenten konsistent sind.
Mama muss sich keine Gedanken über unterschiedliche Umgebungen machen und die abhängigen Pakete, die zu unterschiedlichen Zeiten installiert werden, sind unterschiedlich!
Zusammenfassung
Lassen Sie mich abschließend noch zwei Punkte zusammenfassen:
1. Wenn Sie die Basisbibliothek aktualisieren, müssen Sie auf die Kompatibilität achten. Gehen Sie am besten alle Seiten durch, die diese Basisbibliothek verwenden.
2. Achten Sie während des normalen Entwicklungsprozesses darauf, die automatisch generierte gesperrte Version der Datei package-lock.json einzureichen.