‫Kursleiter:
‫In dieser Vorlesung werden
‫wir über eine Reihe weiterer
‫Dinge sprechen, die Sie über die Arbeit
‫mit npm-Paketen wissen sollten, wie zum Beispiel Versionierung, Aktualisierung oder Löschung von Paketen
‫und auch einige andere Dinge, also fangen wir an.
‫Das erste, worüber
‫ich in diesem Video sprechen möchte, sind diese Versionsnummern unserer Pakete.
‫Die meisten Pakete auf
‫npm folgen der sogenannten semantischen Versionsnotation, was
‫bedeutet, dass ihre Versionsnummern immer
‫mit diesen drei Zahlen ausgedrückt werden.
‫Die erste hier wird als Hauptversion bezeichnet.
‫Die zweite wird als Nebenversion bezeichnet.
‫Die dritte wird als Patch-Version bezeichnet.
‫Diese drei Zahlen haben tatsächlich eine Bedeutung.
‫Die Patch-Version, die hier nur die letzte
‫ist, soll nur Fehler beheben.
‫Sagen wir das in Version 1. 18, die Entwickler fanden einen
‫Fehler und so haben sie diesen Fehler behoben
‫und dann 1 veröffentlicht. 18. 1.
‫Dann fanden sie einen weiteren Fehler
‫und veröffentlichten dann 1. 18. 2 und so weiter und
‫so weiter, bis sie 1 erreicht haben. 18. 11, das
‫ist die aktuelle Versionsnummer.
‫Auch dieser letzte hier ist nur für Fehlerbehebungen.
‫Danach haben wir die Nebenversion.
‫Die Nebenversion führt
‫einige neue Funktionen in das
‫Paket ein, enthält jedoch keine wichtigen Änderungen.
‫Alle Änderungen, die an einer neuen Versionsnummer
‫vorgenommen werden, sind immer abwärtskompatibel.
‫Wenn beispielsweise das Nodemon-Team eines Tages beschließt,
‫Version 1 zu veröffentlichen. 19, nun, das
‫wird dann einige neue Funktionen enthalten, aber
‫es wird unseren Code nicht brechen.
‫Und das gleiche passiert natürlich auch mit diesem hier.
‫Wenn es also eines Tages Slugify 1 gibt. 4, gut, dann
‫wird unser Code immer noch genauso funktionieren.
‫Es wird keine Breaking Changes geben.
‫Es wird einfach etwas Neues
‫geben, also einige neue Features, die nicht nur Bugfixes sind.
‫Bugfixes sind wiederum für die dritte, also
‫für die Patch-Version,
‫und dann kleinere neue Funktionen für die untergeordnete Version.
‫Dann haben wir natürlich die Hauptversion, die nur
‫dann erhöht wird, wenn es
‫sich um eine große neue Version handelt, die bahnbrechende Änderungen enthalten kann.
‫Zum Beispiel, wenn Slugify 2 daherkommt.
‫Nun, unser Code funktioniert möglicherweise nicht
‫mehr, weil die slugify-Funktion, die wir hier haben,
‫beispielsweise ihren Namen geändert hat oder die
‫Parameter, die sie hier erwartet, anders sind oder sich die
‫Optionen geändert haben oder sich etwas
‫geändert hat, das die vorherige
‫Version zerstört. .
‫Beachten Sie, dass eine neue Version normalerweise
‫Auswirkungen auf den Code haben kann,
‫den Sie bereits haben.
‫Aus diesem Grund ist es auch
‫wichtig, über die Aktualisierung von Paketen zu sprechen.
‫In unserem Paket. json-Datei,
‫dieses kleine Symbol hier, das
‫vor der Versionsnummer steht, gibt an,
‫welche Updates wir für jedes der Pakete akzeptieren.
‫Dieses Symbol hier, das npm hier standardmäßig
‫angibt, bedeutet, dass wir Patch- und Minor-Releases akzeptieren.
‫Wie aktualisieren wir nun Pakete eigentlich?
‫Nun, lassen Sie uns diesen Prozess hier tatsächlich beenden.
‫Das erste, was wir
‫tun können, ist zu überprüfen, ob veraltete Pakete vorhanden sind.
‫Wir schreiben npm veraltet, und das sollte uns dann eigentlich eine
‫Tabelle mit allen veralteten
‫Paketen geben.
‫Nun, im Moment sind sie alle auf dem neuesten Stand,
‫also ist das nicht wirklich passiert.
‫Was ich
‫Ihnen jetzt zeigen möchte, ist, dass wir
‫tatsächlich ein bestimmtes Paket mit einer bestimmten Versionsnummer installieren können.
‫Machen wir das mit Slugify und installieren
‫es auf Version 1. 0. 0.
‫Npm installieren slugify und dann bei 1. 0. 0.
‫Probieren wir das aus.
‫Nun haben wir tatsächlich eine Null Null.
‫Wenn wir den Mauszeiger darüber bewegen, wird tatsächlich die
‫neueste Version 1 angezeigt. 3. 4, das hatten wir.
‫Aber wenn wir jetzt npm veraltet ausführen, sollte
‫es uns dann das geben.
‫Wir sehen, dass der Strom 1 ist. 0. 0.
‫Gesucht ist 1. 3. 4, denn das
‫ist diejenige, die wir akzeptieren, denn denken
‫Sie daran, dass wir hiermit alle Patches und alle Nebenversionen
‫akzeptieren, aber natürlich können wir das auch ändern.
‫Zum Beispiel können wir es hier auf dieses Symbol setzen.
‫Dieser akzeptiert dann nur Patch-Releases.
‫Dieser ist etwas sicherer.
‫Wenn wir npm veraltet jetzt wieder ausführen, sehen wir uns
‫an, was wir bekommen.
‫Gesucht wird jetzt nur noch 1. 0. 2, denn
‫auch hier akzeptieren wir nur Nebenversionen.
‫Also 1. 3. 4
‫wird von uns nicht akzeptiert,
‫da wir keine der
‫Nebenversionen akzeptieren, also wieder nur Patch-Versionen.
‫Wenn Sie jetzt npm update slugify durchführen würden, sehen wir uns an, was wir
‫dann bekommen haben.
‫Jetzt sind wir beim 1. 0. 2.
‫Sie sehen,
‫dass sich meine Aktualisierungskonfiguration hier wieder geändert
‫hat, um Neben- und Patch-Versionen zu akzeptieren.
‫Nicht nur die Patch-Releases wie zuvor.
‫Wenn wir das jetzt noch einmal ausführen,
‫sollte es uns tatsächlich bis
‫auf 1 bringen. 3. 4, wie wir vorher hatten.
‫In der Tat, los geht's.
‫Alles klar, so aktualisieren wir Pakete.
‫Es gibt andere Konfigurationen, die
‫wir hier auswählen können.
‫Wir können zum Beispiel sagen, dass wir alle
‫Versionen wollen. Wenn es also irgendwann eine
‫Version 2 gibt und wir unsere Pakete
‫nicht aktualisiert haben, wird
‫unsere Version automatisch auf Version 2 hochgestuft.
‫Dieser enthält alle Versionen,
‫auch solche mit Breaking Changes.
‫Aber das ist normalerweise keine gute Idee,
‫und so gehe ich normalerweise einfach mit dieser
‫Standardeinstellung oder manchmal sogar dieser hier aus, denn irgendwann,
‫selbst wenn ein Minor-Release einfach neue Funktionen einführen sollte,
‫aber keine Breaking Changes, wissen
‫wir das Manchmal kann es Fehler geben, die
‫Entwickler nicht finden, und dann finden diese
‫Fehler ihren Weg in
‫unseren Code und könnten unseren Code brechen.
‫Das wollen wir natürlich nicht.
‫Die sicherste Version ist,
‫diese nur für Fehlerbehebungen zu verwenden.
‫Lassen Sie es uns hier eigentlich einfach so
‫belassen, nur zu Demonstrationszwecken.
‫Das müssen Sie
‫über Versionsnummern und Aktualisierungen wissen.
‫Aber wir können natürlich auch Pakete löschen.
‫Lassen Sie uns jetzt Express
‫installieren, damit wir es danach löschen können.
‫Ich bin sicher, Sie können sich vorstellen, wie wir das machen können.
‫Das ist ganz einfach.
‫Npm uninstall, also heißt es eigentlich nicht löschen.
‫Es deinstalliert wirklich.
‫Wir installieren und deinstallieren Express.
‫Dadurch wird es dann aus unserem
‫Knotenmodulordner und auch aus unseren Abhängigkeiten in
‫einem Paket gelöscht. json-Datei.
‫Jedes Mal, wenn wir uns entscheiden, ein Modul nicht
‫mehr zu verwenden, sollten wir es immer
‫entfernen oder deinstallieren.
‫Als letztes möchte ich noch
‫ein wenig über den Node-Module-Ordner sprechen.
‫Dieser Ordner, der
‫alle Abhängigkeiten unseres Projekts enthält.
‫Angenommen, Sie möchten Ihren Code mit jemandem
‫teilen oder möchten beispielsweise mit der
‫Arbeit an einem Computer
‫beginnen und dann zum nächsten wechseln.
‫Sie werden diesen Knotenmodulordner niemals freigeben, da Sie
‫diesen Code problemlos von npm abrufen können.
‫Sie müssen nicht den gesamten
‫Code hierher kopieren, zum Beispiel
‫in ein GitHub-Repository oder in einen Dropbox-Ordner oder wirklich irgendwo,
‫wo Sie Ihren Code teilen möchten, denn dieser
‫Ordner hier hat, wie
‫Sie sehen, Tonnen von Ordnern und
‫jeder von ihnen kann Tonnen von Dateien haben.
‫Plötzlich können Sie
‫Zehntausende oder Hunderttausende von Dateien haben.
‫Sie sollten diesen Ordner
‫niemals freigeben und niemals in Ihr GitHub-Repository auschecken.
‫Nehmen wir an, Sie haben diesen Code ohne
‫diese Node-Module in Ihr GitHub-Konto hochgeladen oder Sie legen ihn
‫auf einem Computer in eine Dropbox
‫und laden ihn auf dem anderen herunter.
‫Nehmen wir an, wir haben diesen Code jetzt
‫hier heruntergeladen, also ohne Knotenmodule.
‫Also löschen wir diesen
‫jetzt und erhalten nur noch einen normalen Projektordner.
‫Wie bekommen wir jetzt unsere Abhängigkeiten
‫oder unseren Knotenmodulordner zurück?
‫Nun, es ist ganz einfach.
‫Alles, was wir tun müssen, ist npm install.
‫Was es tat, war unser Paket zu lesen. json-Datei, lesen
‫Sie unsere Abhängigkeiten und laden Sie
‫dann alles zurück in diesen Ordner, in Ordnung.
‫Ein wichtiger Teil dieses Puzzles ist
‫nun das Paketschloss. json-Datei.
‫Wenn wir das öffnen, erhalten wir eine
‫Liste aller Versionen aller Pakete, die
‫wir tatsächlich verwenden.
‫Das schließt die Abhängigkeiten unserer Abhängigkeiten ein.
‫Gehen wir zum Beispiel zu Slugify.
‫Slugify, und hier sehen wir, dass wir Version
‫1 verwenden. 3. 4.
‫Das ist sehr wichtig, denn wenn
‫Sie Ihren Code teilen, möchten Sie, dass der
‫andere Entwickler oder sogar
‫Sie genau die gleichen Paketversionen verwenden,
‫damit Ihr Code für Sie und den anderen Entwickler
‫genau gleich funktioniert.
‫Dafür sind die genauen Versionsnummern in
‫diesem Paketschloss grundsätzlich in
‫Stein gemeißelt. json-Datei.
‫Wenn Sie Ihren Code teilen, egal
‫ob Sie GitHub oder Dropbox oder ähnliches verwenden, teilen Sie
‫immer Ihr Paket. json-Datei
‫und die Paketsperre. json-Datei, da
‫diese beiden Dateien für den
‫anderen Entwickler erforderlich sind, um dann
‫im Wesentlichen den Knotenmodulordner zu rekonstruieren.
‫Ja, ich denke, das ist
‫alles, was Sie über Paketversionen, Aktualisieren,
‫Deinstallieren und auch das Teilen von Code mit npm,
‫package. json und Paketsperre. json.
‫Wenn du noch etwas wissen möchtest, kannst
‫du immer wieder im Kurs Q und A nachfragen und
‫dann bekommst du dort Hilfe.