Wie verwaltet NVM mehrere Node.js-Versionen? Methoden zum Wechseln zwischen Node 18, 20, 22 und 24 in Entwicklungsumgebungen und häufige Probleme

Installieren Sie die benötigten Node.js-Hauptversionen einmal mit NVM und wählen Sie anschließend je Terminal oder Projekt die passende Version; prüfen Sie nach jedem Wechsel sowohl node -v als auch den aufgelösten Befehlspfad. Für macOS und Linux ist das POSIX-Shell-Werkzeug nvm-sh gedacht; Windows verwendet eine eigenständige Implementierung mit abweichenden Befehlen und Regeln. (Offizielle Dokumentation von nvm-sh)

Dieser Beitrag hilft Entwicklern, die Projekte mit unterschiedlichen Node.js-Versionen parallel betreuen, und Teams, die Kompatibilität mit Node 18, 20, 22 oder 24 testen. Wer in einem Terminal weiterhin eine alte Version sieht oder nvm gar nicht aufrufen kann, findet weiter unten eine geordnete Fehlersuche.

Zuletzt aktualisiert am 15.10.2026; Versionsstatus anhand der offiziellen Node.js-Release-Übersicht und des Release-Plans geprüft. Die Statusangaben sind eine Momentaufnahme: Node 18 und Node 20 sind bereits am Ende ihres offiziellen Lebenszyklus, während Node 22 und Node 24 als LTS-Linien geführt werden. Für produktive Systeme sollten Sie den offiziellen Status erneut prüfen, bevor Sie eine Version festschreiben. (Node.js: frühere Releases und Status)

NVM verwaltet mehrere Node.js-Versionen über Installation und aktive Shell

NVM installiert unterschiedliche Node-Versionen parallel und ändert beim Wechsel, welche Installation die aktuelle Shell zuerst findet. Das ist besonders hilfreich, wenn ein älteres Projekt noch Node 18 oder 20 voraussetzt, während ein anderes bereits unter Node 22 oder 24 getestet wird. Die Verwaltung der Laufzeit verhindert jedoch nicht automatisch Kompatibilitätsfehler in einer Anwendung: Abhängigkeiten, Build-Werkzeuge und native Module müssen weiterhin mit der jeweils ausgewählten Version geprüft werden.

Der wichtige Unterschied liegt zwischen einer installierten Version und der aktiven Version. nvm ls kann mehrere vorhandene Installationen anzeigen, aber node und npm verwenden in einem Terminal nur die Version, die in dessen Umgebung aktiv ist. Ebenso bedeutet eine Änderung im aktuellen Terminal nicht automatisch, dass bereits geöffnete Entwicklungswerkzeuge, Hintergrunddienste oder andere Shell-Fenster denselben Zustand übernommen haben.

Auch der Versionsstatus ist eine eigene Entscheidungsdimension. Eine ältere Laufzeit kann für eine notwendige Kompatibilitätsprüfung unverzichtbar sein, ist damit aber nicht automatisch eine geeignete Wahl für neue Produktionsbereitstellungen.

Die Enddaten im Release-Plan können sich ändern; sie sind keine Zusage, dass jede Anwendung bis dahin mit einer Version kompatibel bleibt. Node.js weist außerdem darauf hin, dass EOL-Versionen keine reguläre Wartung erhalten und langfristig zu Sicherheits- und Kompatibilitätsproblemen führen können. (Offizieller Node.js-Release-Plan)

Für die Auswahl zählt daher nicht einfach „die neueste Version“. Prüfen Sie zuerst, welche Version das Projekt vorgibt, ob seine Abhängigkeiten damit laufen und ob die betreffende Node-Linie noch gewartet wird. Node 18 und Node 20 können weiterhin für einen reproduzierbaren Altprojekt-Test nötig sein; für einen neuen Standard sollten Sie stattdessen eine gewartete Linie und die Freigabe durch die Projektprüfungen berücksichtigen.

Hinweis: Ein Versionsmanager stellt ältere Releases bereit, verlängert aber nicht deren offiziellen Support. Trennen Sie deshalb klar zwischen „für einen Test erforderlich“ und „für den Dauerbetrieb empfohlen“.

Wie installieren und prüfen Sie Node 18, 20, 22 und 24?

Auf macOS und Linux setzen die folgenden Befehle die POSIX-Implementierung nvm-sh voraus. Die offizielle Dokumentation führt Installation, Shell-Einbindung und Nutzung auf; installieren Sie NVM entsprechend der dort beschriebenen Methode für Ihre Shell, statt ein Windows-Tutorial oder eine beliebige Shell-Zeile ungeprüft zu übernehmen. (Installations- und Nutzungsanleitung für nvm-sh)

Sobald nvm in der Shell verfügbar ist, können Sie die gewünschten Hauptversionen einzeln installieren:

nvm install 18
nvm install 20
nvm install 22
nvm install 24

Die Angabe einer Hauptversion lässt NVM die passende verfügbare Version dieser Linie installieren. Für einen exakt reproduzierbaren Team- oder CI-Test sollten Sie zusätzlich die konkrete Patchversion festhalten, die im jeweiligen Projekt freigegeben ist. Welche Versionen der Downloadquelle aktuell zur Verfügung stehen, lässt sich mit nvm ls-remote prüfen. Anschließend zeigt nvm ls die lokal installierten Versionen; nvm current meldet die aktive Version, und node -v prüft die Ausgabe des tatsächlich aufgerufenen Node-Befehls.

Die Versionsübersicht der Node.js-Projektseite ist die maßgebliche Anlaufstelle, wenn Sie nicht nur wissen möchten, ob eine Hauptversion installierbar ist, sondern auch, ob sie noch LTS- oder EOL-Status hat. Die Release-Seite trennt ausdrücklich zwischen aktuell betreuten Linien und Releases außerhalb der Wartung.

Wie wechseln Sie die aktive Version und setzen den Standard?

Für einen Wechsel nur in der laufenden Shell verwenden Sie nvm use mit der gewünschten Hauptversion:

nvm use 18
node -v
command -v node

Für die anderen Umgebungen ersetzen Sie 18 durch 20, 22 oder 24. Die Versionsausgabe sollte zur Auswahl passen. Mit command -v node prüfen Sie zusätzlich, welcher Pfad für node verwendet wird. Unter Bash oder Zsh können Sie mit type -a node weitere Treffer in der Suchreihenfolge anzeigen lassen; ein älterer Eintrag vor dem NVM-Pfad ist ein Hinweis auf einen PATH-Konflikt.

Die Standardversion legen Sie getrennt davon fest:

nvm alias default 22

Das setzt für neue Shells den Standard auf die aktuelle passende Installation aus der Node-22-Linie. Eine bereits offene Shell kann weiterhin ihre zuvor ausgewählte Version verwenden. Deshalb sollte nach dem Setzen ein neues Terminalfenster geöffnet und darin erneut geprüft werden:

nvm current
node -v
command -v node

Wenn ein neues Terminal nicht die erwartete Version zeigt, prüfen Sie die Shell-Initialisierung, statt die Version mehrfach zu installieren. Die NVM-Dokumentation beschreibt die Einbindung in Shell-Profile und weist auf die Reihenfolge von System-Node-Pfaden und der NVM-Initialisierung hin.

Wie binden Sie die passende Node-Version an ein Projekt?

Eine Datei namens .nvmrc im Projektstamm hält fest, welche Version NVM beim Wechsel in dieses Projekt verwenden soll. Für eine Hauptversion kann sie zum Beispiel nur 22 enthalten. Legen Sie die Datei mit genau dieser Versionsangabe an und prüfen Sie den Inhalt beim Commit gemeinsam mit der Projektkonfiguration. Das macht die erwartete Laufzeit für Teammitglieder sichtbar, installiert sie aber nicht automatisch auf jedem Rechner.

Im Projektverzeichnis können Sie dann ausführen:

nvm install
nvm use
node -v

Bei nvm install und nvm use ohne zusätzliche Versionsangabe liest nvm-sh die passende .nvmrc aus dem aktuellen Verzeichnis oder einem übergeordneten Verzeichnis. Fehlt die angegebene Version lokal, kann nvm install sie installieren und aktivieren.

Diese Verknüpfung ist nicht dasselbe wie ein automatischer Wechsel bei jedem Verzeichniswechsel. Eine .nvmrc dokumentiert die gewünschte Laufzeit; ob ein Wechsel beim Betreten des Ordners automatisch erfolgt, hängt von der verwendeten NVM-Implementierung und zusätzlicher Shell-Konfiguration ab. Ohne eine solche Integration müssen Sie in jedem neuen Terminal ausdrücklich nvm use aufrufen.

Windows weicht hier besonders deutlich ab. Das eigenständige Werkzeug NVM for Windows verwendet andere Befehle und unterstützt das Verhalten von nvm-sh beim Einlesen einer .nvmrc nicht automatisch. Dort wählen Sie die installierte Version mit der Windows-spezifischen Syntax ausdrücklich aus. Übertragen Sie daher keine Beispielbefehle für nvm-sh auf Windows und übernehmen Sie auch keine Behauptung über automatisches Umschalten, ohne die Dokumentation der konkreten Implementierung zu prüfen. (Dokumentation zu NVM for Windows)

Was tun Sie, wenn das Terminal nach dem Wechsel eine alte Version zeigt?

Gehen Sie die Fehlerquelle in einer festen Reihenfolge durch. So vermeiden Sie, dass ein PATH-Problem durch wiederholte Installationen verdeckt wird.

1. Prüfen Sie, ob NVM geladen ist. Führen Sie command -v nvm aus. Wird kein Befehl gefunden, ist NVM in dieser Shell nicht initialisiert. Prüfen Sie, ob die für Ihre Shell vorgesehene Initialisierung im passenden Profil steht und beim Öffnen eines interaktiven Terminals geladen wird. Eine Änderung in einer Profildatei wirkt nicht unbedingt rückwirkend auf ein bereits geöffnetes Fenster.

2. Aktivieren Sie die gewünschte Version erneut. Wechseln Sie in das Projektverzeichnis und führen Sie nvm use aus. Wenn keine .nvmrc vorhanden ist, geben Sie die Hauptversion ausdrücklich an, etwa nvm use 22. Kontrollieren Sie danach nvm current und node -v. Eine zuvor gestartete Shell kann ihren alten Zustand behalten, selbst wenn ein anderes Fenster inzwischen gewechselt hat.

3. Untersuchen Sie die Befehlsauflösung. Rufen Sie command -v node und type -a node auf. Zeigt der erste Treffer auf eine Systeminstallation oder einen anderen Versionsmanager statt auf die durch NVM verwaltete Installation, gewinnt ein anderer PATH-Eintrag. Prüfen Sie dann Shell-Profil, System-PATH und mögliche zusätzliche Node-Installationen. Ein erneuter nvm install ändert diese Reihenfolge nicht von selbst.

4. Prüfen Sie die Shell-Initialisierung und den Standard getrennt. nvm alias default 22 setzt die Version für neue Shells unter nvm-sh; es ist kein Ersatz für nvm use 22 in der aktuellen Sitzung. Öffnen Sie nach einer Profiländerung ein frisches Terminal und wiederholen Sie die Versions- und Pfadprüfung.

5. Installieren Sie fehlende globale Werkzeuge erneut. Globale npm-Pakete sind an den jeweiligen Installationspräfix gebunden. Bei einem Wechsel können daher Werkzeuge wie ein global installierter CLI-Befehl fehlen, obwohl sie unter einer anderen Node-Version vorhanden sind. Prüfen Sie die globalen Pakete in der Zielversion und installieren Sie benötigte Werkzeuge dort erneut. Die npm-Dokumentation erklärt, dass globale Pakete in einem globalen Installationsverzeichnis abgelegt und ausführbare Befehle dort verknüpft werden. (npm-Dokumentation zu global installierten Paketen)

Erfahrungshinweis: Wenn node -v die erwartete Version zeigt, ein Editor oder Build-Prozess aber eine andere meldet, vergleichen Sie nicht nur zwei Terminalausgaben. Prüfen Sie auch, mit welcher Shell und welchen Umgebungsvariablen der Editor, der Task-Runner oder der Hintergrundprozess gestartet wurde.

Unter Windows gilt eine zusätzliche Grenze: NVM for Windows schaltet über eine eigene Installation und Verknüpfung um; vorhandene Node-Installationen oder ein nicht neu gestartetes Terminal können die Diagnose erschweren. Berücksichtigen Sie vor der Einrichtung vorhandene Node-Installationen und öffnen Sie nach einer Änderung eine neue Terminalsitzung. Diese Schritte sind nicht die Fehlerbehebung für macOS, sondern betreffen ausschließlich die Windows-Implementierung.

NVM in einer Remote-Mac-Umgebung reproduzierbar prüfen

Bei einer Remote-Mac-Sitzung reicht eine erfolgreiche Installation im Browser-Terminal oder in einem einzelnen Fenster nicht als Nachweis, dass das Projekt korrekt konfiguriert ist. Entscheidend ist, dass die verwendete Shell NVM lädt, die Projektdatei erkannt wird und die ausgeführten Befehle aus derselben aktiven Node-Installation stammen.

Führen Sie die Prüfung in dieser Reihenfolge aus:

1. Öffnen Sie eine neue Terminal-Sitzung und prüfen Sie command -v nvm. Ist NVM nicht verfügbar, überprüfen Sie das Shell-Profil, das tatsächlich für diese Sitzung verwendet wird.
2. Wechseln Sie in das Projektverzeichnis und lesen Sie .nvmrc. Achten Sie darauf, dass sie die erwartete Hauptversion enthält und nicht versehentlich eine leere Datei oder eine abweichende Angabe im übergeordneten Ordner liegt.
3. Führen Sie nvm install und anschließend nvm use aus. So wird die Projektangabe bei der POSIX-Implementierung explizit angewendet.
4. Vergleichen Sie nvm current, node -v und npm -v. Die Ausgaben sollten zur vorgesehenen Laufzeit passen.
5. Prüfen Sie command -v node und type -a node. Damit erkennen Sie, ob ein alternativer Node-Pfad vor dem verwalteten Pfad liegt.
6. Starten Sie den projektspezifischen Test, Build oder Paketmanager-Befehl genau in dieser Sitzung. Eine passende Versionsnummer beweist allein noch nicht, dass native Module oder Abhängigkeiten mit der ausgewählten Version funktionieren.

Wechseln Sie für einen Kompatibilitätstest gezielt zwischen den benötigten Versionen und wiederholen Sie dieselben Prüfungen. Dokumentieren Sie im Projekt, welche Laufzeit den Test bestanden hat; unterscheiden Sie dabei einen erfolgreichen Start von einem vollständigen Build- und Testlauf. Für Aussagen über konkrete Zilmac-Konfigurationen oder gemessene Ergebnisse liegen hier keine verifizierten Umgebungsdaten vor, daher werden keine Hardware-, Leistungs- oder Verfügbarkeitsangaben gemacht.

Wenn die Umgebung remote bereitgestellt wird, sollten Sie außerdem klären, welche Shell bei jeder neuen Sitzung gestartet wird und welche Profile sie lädt. Für Fragen zu Datenverarbeitung und Datenschutz können Sie die Datenschutzhinweise heranziehen; konkrete technische Eigenschaften einer Remote-Umgebung lassen sich daraus nicht ableiten. Informationen zu tatsächlich angebotenen Mac-Umgebungen finden Sie auf der Seite Cloud-Mac-Umgebungen.

Entscheidung vor dem nächsten Projektwechsel

Für den Alltag ist NVM auf macOS dann die passende Wahl, wenn die Projekte verschiedene Versionen benötigen und der Entwickler bereit ist, den aktiven Zustand pro Shell oder Projekt bewusst zu prüfen. Der Ansatz vermeidet, für jede Projektanforderung Node manuell zu entfernen und neu zu installieren; gleichzeitig verlangt er saubere Shell-Konfiguration und klare Projektvorgaben. Der versteckte Aufwand liegt meist nicht im Installieren selbst, sondern in PATH-Konflikten, getrennten globalen Paketen und dem Irrtum, eine .nvmrc löse den automatischen Wechsel überall von allein.

Für einen lokalen Mac spricht, dass Terminal, Editor und lokale Werkzeuge ohne Netzwerkverbindung arbeiten können und vorhandene Hardware direkt verfügbar ist. Dagegen stehen die Pflege des eigenen Rechners, abweichende Zustände zwischen lokalen Benutzerkonten und die Notwendigkeit, ein Projektsetup selbst über mehrere Geräte hinweg konsistent zu halten. Eine Remote-Mac-Umgebung ist nicht automatisch besser: Sie kann von Netzwerkzugriff und den tatsächlich angebotenen Eigenschaften abhängen und ist ungeeignet, wenn ein lokaler physischer Anschluss erforderlich ist. Vor einer Entscheidung sollten Sie deshalb den Projektbedarf, den Terminalzustand und den Node-Befehlspfad vergleichen.

Kurze Wechselprüfung: Stimmen Projektvorgabe und .nvmrc überein? Ist die richtige Version in der aktuellen Shell aktiv? Zeigen node -v und command -v node auf die erwartete Installation? Sind die global benötigten Werkzeuge für diese Version verfügbar? Wenn ein neuer oder temporärer Remote-Mac-Entwicklungsplatz sinnvoller ist als die Pflege des lokalen Setups, prüfen Sie zuerst die konkreten Angaben zu den bei Zilmac tatsächlich verfügbaren Umgebungen, bevor Sie sich festlegen.