nvm Was Created by Tim Caswell in 2010 and Later Maintained by Jordan Harband

If you build software with Node.js for more than a few weeks, you have almost certainly typed nvm install followed by a version number. The Node Version Manager is one of those quiet tools that everyone relies on and almost nobody credits. It was created in 2010 by Tim Caswell, a name you might recognize from early Node ecosystem work, and it was later taken over and maintained for years by Jordan Harband, who shaped it into the tool developers reach for daily.

Caswell wrote nvm because the problem it solves was fresh and real in 2010. Node itself was new, still in its 0.x era, and versions changed meaningfully and often. If you maintained a library or ran an application, the Node version you had installed could determine whether your code worked at all. The natural fix was a way to install and switch between multiple Node versions on one machine without fighting your system package manager or rebuilding from source each time.

The key design choice that made nvm work was to keep it a plain POSIX shell script. That decision deserves respect. Because nvm runs as a shell function, it can change the environment of your interactive shell directly. It can alter the PATH and set up symlinks in a way that persists for the current session, which a compiled program launched as a child process could never do. The oldest, least glamorous technology turned out to be the technically correct one for the job.

Harband became the maintainer in the years after Caswell moved on to other projects, and his stewardship is a large part of why nvm stayed relevant as the ecosystem grew. Version management went from a curiosity to a necessity as the Node community found itself needing not just one version but several, often across different projects on the same machine. The .nvmrc file, which lets a project pin its preferred Node version and have nvm use load it, became a small convention that made reproducibility much easier.

The senior developer lesson here is broader than one tool. Good maintainership is what separates a nifty script from an ecosystem staple. The technical foundation mattered, but so did years of careful handling: responding to issues, keeping the tool compatible across shells and operating systems, and resisting the urge to add over-engineered features. A humble tool that runs everywhere and does exactly one thing reliably tends to outlast far more impressive projects.

There is also a practical habit worth adopting from how nvm is used. Pin your versions. On a real team, each project should carry an .nvmrc and a committed package lock file so that everyone runs the same Node and the same dependencies. Relying on whatever version happens to be installed on your laptop is how environment bugs sneak into production. Version managers exist precisely so that this kind of drift does not happen.

So the next time you run nvm use or nvm alias default, you are standing on a small piece of history. A tool born in 2010 to cope with a fast-moving young runtime, kept alive by careful hands, still quietly standardizing Node development today. Tim Caswell gave it life and Jordan Harband gave it endurance, and between them they produced a utility most of us no longer think about because it simply works.