Because nodenv was forked from rbenv, many of the reasons to choose nodenv over others are similar to why one would choose rbenv over rvm. (Nodenv also inherits a much longer battle-tested history than others.)
One of the biggest reasons to choose nodenv over the others is that nodenv can automatically select the appropriate node version for a given project. Neither nvm nor n have auto-switching capabilities out of the box. They both require some form of 'use' command to activate a given version; which lasts for the lifetime of the shell (or until another version is activated).
To gain autoswitching capability, one must use avn in conjunction with either nvm, n or nodebrew.
However, avn requires overriding the builtin shell commands cd, pushd and popd; which can be considered dangerous and error prone.
(ie, what happens if a user has their own cd-wrapping functions, or perhaps a cd alias, etc)
Nodenv accomplishes its auto switching by inserting a directory of shims into $PATH.
This means nodenv does not need to have anything loaded into the shell itself [1]; nor rely on overriding builtin shell commands.
- While nodenv doesn't require shell integration for functionality, it is recommended to include nodenv-init in your shell startup. This defines a
nodenvwrapper function which ensures the shell's command lookup cache gets cleared whenever nodenv rehash is run; and also adds a helpful subcommand for setting/clearing the active node version per shell instance.
Since nodenv doesn't require shell integration or overriding of builtin commands, nodenv adds no performance penalty to shell startup nor to commands that don't involve running node itself. Contrast this with nvm which requires being loaded into the shell; or avn which needs to run code every time you change directories.
nodenv supports bash, fish and zsh. nvm does not support Fish, nor does it work reliably on FreeBSD
A special note in contrast to n;
nodenv does not alter or modify the installed node_modules (or the node bin itself) when switching between them.
n on the other hand, shares a single global node_modules, which may need recompiled between nodes.
n also resets npm to the stock version each time you switch node versions.
This means if you install the latest version of npm in a node version, when you switch to a different node version and back you will no longer be on the latest npm.
With nodenv, it is trivial to have multiple versions of the same node release, each with different versions of npm. Or even to have multiple nodes with different compile-time flags, all for the same node release.
Owing to its heritage, nodenv has the exact same command interface as rbenv itself (and other rbenv derivatives, like pyenv or jenv). This is particularly helpful for developers who work in both node and ruby or python (or other), as you have an identical set of commands for version switching across multiple languages.
Even more than just CLI commands themselves, the semantics of those commands and how the *env tools behave are the same. This is tremendously helpful when debugging, for if you know one *env tool, you know them all.