nvm-desktop: Node.js-Versionen über Shims in ~/.nvmd statt über Shell-Funktionen

nvm-desktop und nvmd greifen auf denselben Bestand zu

1111mp/nvm-desktop bringt zwei Zugänge mit: die gleichnamige Desktopanwendung und das Kommandozeilenwerkzeug nvmd. Laut README sind das keine getrennten Welten, sondern zwei Oberflächen auf demselben Zustand. Eine Version, die über die eine Seite installiert wird, ist auf der anderen sichtbar.

Unterstützt werden macOS, Windows und Linux. Das README beschreibt die Aufteilung knapp und praktisch: Die Grafikoberfläche dient dem Entdecken und der visuellen Verwaltung, nvmd der Automatisierung, Skripten und terminalnaher Arbeit.

Ob beide Teile in einem Installer gebündelt oder getrennt verteilt werden, steht dort nicht. Das ist die erste Frage, die man vor einer Team-Einführung klären sollte, weil eine halb installierte CLI in einem CI-Skript erst spät auffällt.

Installation über GitHub Releases und drei Prüfbefehle

Als einzigen Verteilungsweg nennt das README die Seite der GitHub-Veröffentlichungen. Hinweise auf einen Paketmanager fehlen, es gibt also keine dokumentierte brew-Formel und keinen winget-Eintrag, soweit das Material reicht. Wer mehrere Rechner ausstattet, baut sich das selbst.

Nach der Installation empfiehlt das README, im Terminal drei Befehle zu prüfen:

nvmd -V node -v npm -v

Der Sinn dieser Prüfung liegt auf der Hand: Sie zeigt, ob die Shims im PATH angekommen sind. Wie der Installer das auf jeder Plattform erreicht und was zu tun ist, wenn einer der Befehle nicht gefunden wird, erklärt das README nicht. Genau diese Lücke ist im Alltag die häufigste Fehlerquelle bei Versionsverwaltern.

Zur Einordnung der Reife lassen sich die Veröffentlichungen heranziehen, ohne daraus ein Qualitätsurteil abzuleiten: v4.3.2 am 10. April 2026, v4.3.3 am 13. Juni 2026 und v4.4.0 am 28. Juli 2026.

Die dokumentierten nvmd-Befehle von install bis which

Das README stellt die Nutzung als Abfolge von sieben Schritten dar, jeder mit einem konkreten Beispiel. nvmd install 20.18.0 lädt eine Version herunter, nvmd ls listet die installierten Versionen auf, und nvmd use 20.18.0 setzt die globale Standardversion.

nvmd current zeigt die aktive Version, nvmd uninstall 16.20.2 entfernt eine wieder. Für Skripte am nützlichsten ist nvmd which, denn nvmd which node und nvmd which npm geben den aufgelösten Pfad der ausführbaren Datei aus. Wer Build-Skripte schreibt, kann damit prüfen, welche Laufzeit tatsächlich zum Zug kommt, statt es zu vermuten.

Wichtig ist die Einschränkung, die das README selbst setzt: Diese Befehle werden als zentraler Arbeitsablauf präsentiert, nicht als vollständige Befehlsreferenz. Optionen darüber hinaus sind damit nicht abgedeckt, und eine Hilfeausgabe wird im Material nicht gezeigt.

--project und projects.json für eine Version je Repository

Über das globale Umschalten hinaus erlaubt nvmd use 18.20.4 --project, eine Version für das aktuelle Projekt zu setzen statt für das gesamte System. Der empfohlene Ablauf ist kurz: Projektverzeichnis öffnen, Befehl mit der gewünschten Version ausführen, mit node -v bestätigen, danach wie gewohnt Abhängigkeiten installieren.

Das Ziel ist laut README ein konsistentes Verhalten von Abhängigkeiten und Toolchain pro Repository. Praktisch heißt das, dass ein Legacy-Projekt auf einer alten Laufzeit bleiben kann, während ein neues daneben eine aktuelle nutzt, ohne dass man bei jedem Wechsel im Verzeichnisbaum daran denken muss.

Gespeichert wird diese Bindung in der Datei projects.json im Datenverzeichnis. Damit ist sie eine Textdatei mit Zustand, die man in ein Sicherungskonzept aufnehmen muss. Was passiert, wenn ein Projektverzeichnis verschoben oder umbenannt wird, beschreibt das README nicht.

Aufbau des Datenverzeichnisses ~/.nvmd

Die Daten liegen unter ~/.nvmd auf macOS und Linux, unter %HOMEPATH%\.nvmd auf Windows. Der Aufbau ist dokumentiert und erstaunlich aufschlussreich, weil er den Mechanismus erklärt, den das README sonst nicht beschreibt.

Das Verzeichnis bin enthält Shims für node, npm, npx, nvmd und corepack. Das Verzeichnis versions enthält die installierten Laufzeiten. Eine Datei namens default hält die globale Version, projects.json die projektbezogenen Bindungen und setting.json die Anwendungseinstellungen.

Aus dieser Struktur folgt, wie das Umschalten funktioniert: Nicht die Shell ersetzt ihren Pfad, sondern ein fester Eintrag im PATH zeigt auf ein Shim, das die aktive Version auflöst. Das hat den Vorteil, dass es ohne Shell-Initialisierung funktioniert, und den Nachteil, dass der Eintrag stimmen muss. Welche Spiegelserver-Optionen oder Sprachen setting.json im Einzelnen aufnimmt, wird nur als Beispiel genannt und nicht aufgeschlüsselt.

Getrennte globale npm-Pakete und der Vergleich mit nvm und fnm

Eine Frage beantwortet das README ausdrücklich: Globale npm-Pakete werden zwischen Node.js-Versionen nicht geteilt, die Umgebungen sind getrennt. Wer ein gemeinsames Verzeichnis möchte, setzt einen gemeinsamen Präfix:

npm config set prefix "/path/to/shared-global"

Diese Trennung ist Absicht, überrascht aber beim ersten Versionswechsel, wenn ein Kommandozeilenwerkzeug plötzlich fehlt.

Zum Vergleich mit anderen Verwaltern: Das vorliegende Material nennt nvm unter nvm-sh/nvm und fnm unter Schniz/fnm, beschreibt deren Arbeitsweise aber nicht. Wie diese beiden den Wechsel technisch umsetzen, lässt sich daraus nicht ableiten. Ein belastbarer Vergleich setzt dort an, wo nvm-desktop selbst konkret wird, also bei den Shimen unter ~/.nvmd/bin, der Datei default für die globale Version und projects.json für projektbezogene Bindungen. Wer zwischen den Werkzeugen wählt, sollte genau diese drei Stellen in der Dokumentation der jeweils anderen Seite suchen und gegenüberstellen, statt sich auf pauschale Vergleiche zu verlassen.

Rust, pnpm und src-tauri beim Bauen aus dem Quellcode

Für die lokale Entwicklung nennt das README Rust, Node.js und pnpm als Voraussetzungen. Der Ablauf besteht aus drei Schritten: pnpm check, pnpm install und pnpm dev zum Ausführen. Ein Paket entsteht mit pnpm build, die Artefakte liegen anschließend unter ./src-tauri/target/release/bundle.

Der Pfad src-tauri zusammen mit der Rust-Voraussetzung deutet auf Tauri als Grundlage der Desktophülle hin. Das README selbst benennt das Framework an keiner Stelle, der Standardbranch des Repositorys heißt jedoch tauri, und das Topic-Verzeichnis führt tauri ebenfalls. Aus dem Material folgt die Verwendung daraus, nicht aus einer ausdrücklichen Aussage.

Das Repository steht unter der MIT-Lizenz, das Urheberrecht wird im Material mit 2023 bei 1111mp angegeben. Die Lizenz erlaubt Nutzung, Kopie, Veränderung, Zusammenführung, Veröffentlichung, Vertrieb, Unterlizenzierung und Verkauf, solange Urheberrechts- und Lizenzvermerk erhalten bleiben, und schließt Gewährleistung sowie Haftung aus. Zur Sicherheitslage, zu einem Supportkanal oder zur Handhabung von Fehlermeldungen steht dort nichts.

Redaktionelles Fazit

nvm-desktop passt für Entwickler, die mehrere Node.js-Versionen parallel halten, sie pro Repository festlegen wollen und dabei zwischen Klick und Kommandozeile wechseln. Weniger geeignet ist es für Umgebungen, die eine Installation über einen Paketmanager und eine dokumentierte PATH-Einbindung verlangen, sowie für Arbeitsweisen, die auf gemeinsame globale npm-Pakete über Versionsgrenzen hinweg angewiesen sind, weil die Trennung hier Standard ist und nur über npm config set prefix aufgehoben wird. Vor einer Einführung im Team gehören drei Punkte geprüft: ob nvmd -V, node -v und npm -v nach der Installation im Terminal ankommen, ob projects.json im eigenen Sicherungskonzept berücksichtigt ist, und ob die verfügbare Version v4.4.0 vom 28. Juli 2026 zur eigenen Plattform passt.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes