nvm-desktop review: a Tauri-based Node version manager with GUI and CLI
Node Version Manager Desktop - A desktop application to manage multiple active node.js versions.
At a glance
- What is it?
- nvm-desktop is a cross-platform Node.js version manager that pairs a Tauri GUI with the nvmd command-line tool. It targets developers who want per-project Node versions without abandoning the terminal.
- Who is it for?
- Adopt nvm-desktop if you want a single tool that covers both GUI discovery and CLI automation for Node version management on macOS, Windows, or Linux, and you are comfortable with a project that stores data in ~/.nvmd and uses shims. Skip it if you prefer a pure terminal workflow with a more established ecosystem, or if you need per-project versions without an explicit --project flag on every command.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What nvm-desktop solves and who it is for
nvm-desktop addresses a recurring pain point for Node.js developers: juggling multiple installed Node versions and keeping them consistent across projects. The classic nvm (for Unix) and nvm-windows exist, but they are terminal-only and often platform-specific. nvm-desktop offers both a GUI and a CLI, so a developer can click through version discovery in the desktop app and still script version switches with nvmd. The README explicitly targets users who want to install, uninstall, switch, and pin Node versions while keeping environments isolated. The intended audience is broad: frontend engineers, backend Node developers, and anyone who maintains several repos with different Node requirements. The project is written in TypeScript, which suggests the core logic is shared between the GUI and CLI, though the desktop shell is built with Tauri.
The two-sided architecture: GUI plus CLI
The project ships two interfaces. The GUI app, also called nvm-desktop, is the visual layer for browsing available versions, installing and uninstalling them, switching the global default, binding versions to projects, and adjusting settings like mirror and language. The CLI tool, nvmd, is the terminal counterpart. The README describes the CLI as the primary workflow, listing commands like nvmd install 20.18.0, nvmd use 20.18.0, and nvmd use 18.20.4 --project. This dual design means a user can start with the GUI for exploration and then move to the CLI for repeatable actions. The data layer is shared: both interfaces read and write the same state under ~/.nvmd (or %HOMEPATH%\.nvmd on Windows). That shared state is what makes the two interfaces interchangeable, though the README does not detail how the GUI and CLI communicate internally.
How version management works under the hood
The README gives a clear picture of the runtime layout. nvm-desktop stores installed Node.js runtimes in a versions directory, and it creates shims in a bin folder for node, npm, npx, nvmd, and corepack. These shims are the key mechanism: they redirect calls to the currently selected Node version. The default file holds the global default version, and projects.json stores per-project version bindings. When you run nvmd use 18.20.4 --project, the tool writes that binding into projects.json, and subsequent node or npm invocations in that project directory resolve to the pinned version through the shims. This is a common pattern in version managers, but the explicit projects.json file is a concrete implementation detail. The setting.json file holds app settings, including the mirror option, which is useful in regions where the default Node download source is slow. The README does not explain the exact shim resolution algorithm, so the precise precedence between the project binding and the global default is not documented.
Getting started: install and core commands
Installation is straightforward: download a release from GitHub Releases and run it. After installation, the README says you should verify that nvmd -V, node -v, and npm -v are available in your terminal. That implies the installer sets up the PATH or the shims are placed in a directory already on your PATH. The core CLI commands are simple and follow a familiar pattern. nvmd install 20.18.0 fetches and installs that Node version. nvmd ls lists installed versions. nvmd use 20.18.0 switches the global default, and adding --project pins the version for the current project. nvmd current reports the active version. nvmd uninstall removes a version. nvmd which node and nvmd which npm print the executable paths, which is handy for tooling that needs the absolute path. For local development of the project itself, the README lists prerequisites: Rust, Node.js, and pnpm. Then you run pnpm check, pnpm install, and pnpm dev. Building produces artifacts in ./src-tauri/target/release/bundle. That build path confirms the Tauri backend, which compiles a Rust binary for the desktop shell.
Per-project pinning and the recommended workflow
The README recommends a specific workflow for each project: open the project root, choose a Node version with nvmd use <version> --project, run node -v to confirm, then install dependencies and develop. This is a sensible pattern for teams that need consistent toolchain behavior across environments. The per-project binding lives in projects.json, which is a plain JSON file that could be committed to version control if a team wants to share bindings, though the README does not suggest that. A notable detail is that the binding is set from the project root, and the README does not specify whether subdirectories inherit the binding. This could be a limitation for monorepos where different packages under one root need different Node versions. The workflow is manual: you must remember to run nvmd use --project each time you clone a repo. There is no mention of automatic detection from a .nvmrc or engines field, which is a feature in some other version managers.
Isolation and global package sharing
The FAQ addresses a common question: are global npm packages shared between Node versions? The answer is no by default, because environments are isolated. This is a deliberate design choice that prevents version conflicts, but it also means that globally installed packages like a CLI tool must be reinstalled for each Node version. The README offers a workaround: set a common prefix with npm config set prefix "/path/to/shared-global". That is a practical tip, but it requires each user to configure it manually. The isolation model is a trade-off. It keeps each Node version clean, but it adds overhead for developers who rely on a set of global tools. The README does not mention any built-in mechanism to sync global packages across versions, so the prefix setting is the only documented path.
Limitations and when it is the wrong tool
The most obvious limitation is that the README is thin on details about failure modes. It does not describe what happens when a download fails, how the shims behave in a restricted shell, or whether the GUI can run without a display (it cannot, by definition). The project is also young: the latest release is v4.4.0 from July 2026, and the default branch is named tauri, which suggests the architecture is still in flux. That means upgrade costs could be non-trivial if the data format or CLI syntax changes between releases. The tool is the wrong choice for a developer who wants a zero-dependency, POSIX-only version manager that integrates with a shell startup file (like nvm does). It is also overkill for a developer who only needs one Node version and never switches. The GUI adds a system tray or window, which is unnecessary for a headless CI environment. In CI, you would use a Docker image or a setup-node action instead of a desktop app.
Alternatives and how they differ
The most direct alternative is the original nvm (node version manager) for Unix, which is a shell script that loads a function into your shell. nvm works by modifying the PATH and setting environment variables in the current shell session, and it does not have a GUI. nvm-windows is a separate tool for Windows that uses symlinks and an admin command prompt. The key difference is that nvm-desktop uses shims in a bin directory, which do not require shell integration or admin privileges. Another alternative is fnm (Fast Node Manager), which is a Rust-based CLI that also uses shims and supports per-project versions via a .node-version file. fnm is terminal-only, but it is faster and has a simpler data model. Volta is another alternative: it pins Node and npm versions per project via package.json and manages the toolchain automatically. Volta's approach is more integrated with the npm ecosystem, whereas nvm-desktop requires an explicit nvmd use --project command. The choice depends on whether you prefer a GUI, a specific pinning mechanism, or shell integration.
Maintenance and licensing
The project is licensed under MIT, which is permissive and allows commercial use, modification, and redistribution with attribution. The repository is not archived, and the last push was August 2026, with a release in July 2026, so it appears actively maintained. The development setup requires Rust, Node.js, and pnpm, which is a heavier toolchain for contributors compared to a pure JavaScript project. The build artifacts are produced by Tauri, which means the desktop app is packaged per platform. The README does not mention any upgrade path for existing installations, so users must check release notes for breaking changes. The data directory is versioned under ~/.nvmd, and there is no documented migration tool, so upgrading the app might require manual intervention if the data format changes. Given the recent release cadence, this is a project to watch, but the maintenance cost for a user is low: the CLI is simple, and the data files are plain text. The licence is a positive sign for adoption in commercial settings.
Editorial conclusion
Adopt nvm-desktop if you want a single tool that covers both GUI discovery and CLI automation for Node version management on macOS, Windows, or Linux, and you are comfortable with a project that stores data in ~/.nvmd and uses shims. Skip it if you prefer a pure terminal workflow with a more established ecosystem, or if you need per-project versions without an explicit --project flag on every command. Before adopting, verify that the current release (v4.4.0) matches your platform's installer format, test the shims in your default shell, and confirm that the per-project binding in projects.json behaves as expected with your monorepo layout. The project is under active development with recent releases, but the default branch is named tauri, which signals that the architecture is still evolving.
Community notes