Möchten Sie schnell die Node-Version wechseln? nvm ist das richtige Tool für Sie.
Erste Schritte
Warum nvm? Node ist eine ausführbare Datei. Beispielsweise unter Linux, wenn Sie das Paket Ihrer Distribution installiert haben, wird es in einem Verzeichnis vom Typ /usr/local/bin.
Das Problem ist, dass diese ausführbare Datei einer bestimmten und festen Version entspricht und nur von Ihrem Paketmanager auf eine neuere Version aktualisiert werden kann.
nvm ermöglicht es Ihnen hingegen, mehrere Versionen auf derselben Maschine koexistieren zu lassen.
1. Installation
nvm verfügt über mehrere Installationsmethoden, darunter ein Skript zur automatischen Installation. Zum Zeitpunkt der Veröffentlichung dieses Artikels können Sie starten (siehe
le README) :
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash
Dieses Skript installiert nvm in ~/.nvm und fügt Zeilen zur Konfigurationsdatei Ihrer Shell hinzu, die ausgeführt werden müssen, damit nvm funktioniert. Um nvm zu verwenden, öffnen Sie eine neue Shell oder führen Sie den Befehl aus source [Datei] wobei [Datei] das Konfigurationsskript Ihrer Shell ist (~/.bashrc, ~/.zshrc oder eine andere, je nach Fall)
Sie können die Liste der zum Herunterladen verfügbaren Node-Versionen sehen, indem Sie Folgendes ausführen:
nvm ls-remote
2. Verwendung
Wir werden zwei verschiedene Node-Versionen installieren:
nvm install 12.16.3
Ein node -v zeigt Ihnen, dass die ausführbare Datei Version 12.16.3 ist.
nvm install 14.3.0
Ein node -v zeigt Ihnen, dass die ausführbare Datei Version 14.3.0 ist, und wenn diese Version diejenige ist, die Sie für Ihr Projekt benötigen, können Sie diese direkt starten!
Sie können dann die Version frei ändern, indem Sie Folgendes verwenden: nvm use [Versionsnummer].
Um die Magie hinter nvm besser zu verstehen, erkunden wir die Struktur des Installationsordners.
Das Installationsskript hat das Git-Verzeichnis nach ~/.nvm.
ls ~/.nvm
Der praktisch wichtigste Ordner ist derjenige namens versions/node, der die installierten Versionen in verschiedenen Ordnern speichert und sie koexistieren lässt.
cd ~/.nvm/versions/node
Sie sollten die folgende Struktur sehen:
Die Struktur des Unterordners `~/.nvm/versions/node`
In jedem Unterordner gibt es ein Verzeichnis bin das die ausführbaren Dateien sammelt, die der jeweiligen Version entsprechen (npm und npx sind symbolische Links).
Sie können nun überprüfen, dass ./v12.16.3/bin/node -v und ./v14.3.0/bin/node -v Ihnen die erwarteten Versionsnummern liefern.
Sie können diese Installationspfade finden, indem Sie Folgendes ausführen:
nvm which current
nvm which 12.16.3
Wechseln Sie noch schneller die Version
Wenn Sie an vielen Projekten arbeiten und sich in den Versionsnummern verlieren, sollten Ihnen die folgenden Aliase das Leben erleichtern:
nvm alias project1 12.16.3
nvm alias project2 14.3.0
Sie können nun die Version direkt ändern mit nvm use project1 und nvm use project2.
Es gibt nützliche Aliase, die bereits konfiguriert sind, die Sie sehen können, indem Sie Folgendes eingeben: nvm alias und dann Tabulator im Terminal:
Wenn Sie überhaupt nichts schreiben möchten, ist dies auch möglich! Platzieren Sie eine Datei .nvmrc im Stammverzeichnis Ihres Projekts und verwenden Sie nvm use, nvm install ohne eine Version darin anzugeben.
Die Versionen im Node.js-Universum
Sie haben vielleicht bemerkt, dass die Node- und npm-Versionen die folgende Form haben:
X.Y.Z
Und es ist kein Zufall, dass dieses Format auch dasjenige Ihrer Pakete ist in Ihrer package.json und package-lock.json.
Unter dem Namen semver ist die semantische Versionsverwaltung im Zentrum des Ökosystems, und jeder JavaScript-Entwickler würde davon profitieren, sie zu beherrschen.
Die erste Zahl „X“ entspricht der Hauptversion: wenn diese Zahl inkrementiert wird, bedeutet dies, dass die neue Version nicht rückwärtskompatibel mit der vorherigen Version ist.
Die zweite, „Y“, entspricht der Nebenversion. Eine Änderung bedeutet, dass mehr Funktionen verfügbar sind oder dass einige veraltet sind, aber dass die API rückwärtskompatibel bleibt. Die Version „Z“ weist auf eine Fehlerbehebung hin.
Man muss „Z“ auf null setzen, wenn man „Y“ inkrementiert, und man muss „Y“ und „Z“ auf null setzen, wenn man „X“ inkrementiert.
Vorsicht jedoch: nichts hindert einen Entwickler daran, „X“ oder „Y“ zu inkrementieren, indem er sein npm-Paket online stellt, und leider,
Irren ist menschlich.
Ein kurzer Abstecher in das package.json
In Ihrem package.json haben Sie sicherlich schon diese Versionsnummern mit Dekorationen versehen gesehen: “^4.12.2”, “<=12.0.1”, “~0.4.77” oder auch nicht, wie bei “1.0.3”. Manchmal sehen Sie sogar komplizierte Anordnungen: “<1.0.0 || >=2.5.1” oder auch “>4.0.1 <=5.3.0”.
Hier ist die Übersetzung:
1.0.3: npm muss Version 1.0.3 installieren, und es wird ihm kein Spielraum gelassen;
^4.12.2: npm muss die aktuellste Version ab 4.12.2 (einschliesslich) installieren, aber nicht die nach 5.0.0. Im Grunde keine Version, die nicht rückwärtskompatibel mit 4.12.2 ist;
~0.4.77: npm muss die neueste Version 0.4.x installieren;
<=12.0.1: entweder Version 12.0.1, falls sie existiert, oder eine frühere Version. Das kann nützlich sein, um npm die Wahl zu lassen, zum Beispiel wenn ein anderes Paket dieses package in Version 11.0.6 benötigt.
“<1.0.0 || >=2.5.1”: alle Versionen ausser jenen zwischen 1.0.0 und 2.5.0 (deren API uns möglicherweise nicht passt).
“>4.0.1 <=5.3.0”: alle Versionen zwischen 4.0.2 und 5.3.0 einschliesslich.
Wenn diese Beispiele Ihre intensive Neugier nicht gestillt haben, können Sie sich mit
dem Parser von npm.
Die node-Versionen
node ist eine ausführbare Datei, deren Versionen dem “Semantic versioning” folgen.
Sein Release-Zyklus ist sehr regelmässig, da alle 6 Monate eine neue Hauptversion erstellt wird.
Ungerade Hauptversionen (13.*.*, 15.*.*, etc.) werden nach 6 Monaten eingestellt. Gerade Hauptversionen (14.*.*, 16.*.*, etc.) erfahren nach diesen 6 Monaten ein anderes Schicksal:
sie werden in Langzeit-Support (LTS) überführt, ein Support, der 12 Monate dauert. Updates und Fehlerbehebungen können stattfinden;
Am Ende dieser Periode werden sie für weitere 18 Monate gewartet, während derer Bugs behoben werden.
Fazit: Wenn Sie ein Projekt starten oder dessen Version aktualisieren, bevorzugen Sie die aktuelle gerade Hauptversion von node.
Fehler aufgrund von node-Versionen
Nehmen wir an, wenn Sie ausführen npm install, npm sich beschwert, indem es schreibt:
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE package: '@angular-devkit/core@x.y.z',
npm WARN EBADENGINE required: { node: '>= 12.4.0 <12.9.1', npm: '^6.10.0 || ^7.5.6',},
npm WARN EBADENGINE current: { node: 'v18.18.0', npm: '9.8.1' }
npm WARN EBADENGINE }
Es sollte also Folgendes gelten:
eine node-Version grösser als oder gleich 12.4.0 und kleiner als oder gleich 12.9.0 (derzeit ist dies nicht der Fall, da npm Version 18.18.0 hat)
eine npm-Version zwischen 6.10.0 einschliesslich und 7.0.0 ausschliesslich oder zwischen 7.5.6 einschliesslich und 8.0.0 ausschliesslich (derzeit ist dies nicht der Fall, da npm Version 9.8.1 hat).
Ein kurzer Abstecher zu nvm ls-remote zeigt mir die möglichen Versionen nach 12.4.0 an.
nvm use 12.4.0 zeigt mir, dass diese Version mit npm Version 6.9.0 geliefert wird, was gemäss meiner Fehlermeldung nicht passt.
Nach einigen Installationen stelle ich fest, dass die node-Version 12.7.0 passt und meine Fehlermeldung löst.
Ich kann unnötige Versionen deinstallieren, indem ich nvm uninstall [version].
Fazit
nvm ist ein Dienstprogramm, das sehr nützlich sein kann, wenn Sie die node-Version auf dem Server nicht kontrollieren, wenn Sie an einem Projekt arbeiten, bei dem ein spontanes Update im Vergleich zu anderen Mitarbeitern unerwünscht wäre, oder wenn letzteres bestimmte alte Pakete beschädigen würde. Es gibt andere Versionsmanager für
node wie
n (
hier verfügbar), aber die Anzahl der Versionen ist begrenzter.