Skip to content

Welcome to nvm-windows Discussions! #565

Welcome to nvm-windows Discussions! #565
Aug 27, 2020 · 6 answers · 18 replies

👋 Welcome!

Use Discussions as a place to connect with other members of our community. We hope that you:

  • Ask questions you’re wondering about.
  • Share ideas.
  • Engage with other community members.
  • Welcome others and are open-minded. Remember that this is a community we
    build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.


6 suggested answers
18 replies

coreybutler Aug 27, 2020
Maintainer Author

Hi, I'm Corey.

I created NVM for Windows to fill a gap in the Node community and make Windows developers first class citizens as Node evolved. It first started right before io.js split and merged back into Node. The project has grown alot since those days.

NVM4W is one of the more popular projects I've released, with over 2.5M downloads (not all from Github). There have been some absolutely stellar contributors who have helped move this project forward over the years. I, and the community, owe them a debt of gratitude.

I am hoping to use this discussion feature to help provide better progress updates, project intentions, goals, etc. I intend to close down the gitter channel in favor of this. I also hope to answer questions, starting.... now.

Is this project dead?

Absolutely not. I know it seems like it takes a long time for releases. There's no denying, the 1.1.8 release has been significantly delayed. The truth is I have had alot of life turbulence, both good and bad, and it has been incredibly hard to keep up. Over the last 18 months, I've been predominantly working on macOS, so it has been difficult to test changes. The DevOps process, installers, and even Go underwent major changes. I started work on Github Actions during the beta to facilitate faster releases, then Github changed from HCL to YAML, ditched the visual editor, and pretty much changed the way everything works. I was also hard at work on Fenix Web Server 3.0.0, a project that preceded this one and was in dire need of updates. The bottom line is I have been busy, and this project isn't exactly putting food on the table. Sponsorship has really only picked up meagerly in the last 2 months, and to date this project still operates at a loss (the code signing certificate costs more than the lifetime earnings of this project).

That said, I am gradually coming up for air and finding time to notate new features, revisit old requests, etc.

What is the holdup on forward progress?

Currently, my focus is releasing, a new startup I'm working on with @gbdrummer. We completed Y-Combinator Startup School earlier this year and have been working overtime to bring it to life. You can probably guess that our beachhead effort is Go documentation (yes, JS is high on the roadmap), and the NVM code base has been our test bed. The plan is to start work on environment management after Metadoc is released. We're hoping for a mid-September launch, but COVID has impacted our timeline and resources. We're still hopeful to release without much further delay. Once launched, I will have a chance to dedicate time to this project.

When will 1.1.8 be released?

1.1.8 has been in the master branch for over a year, unreleased. While I have confidence it works well, I was attempting to get an automated testing system setup around the new version. There are many companies, CI/CD services, and others depending on this project, so releasing without proper testing would be a little reckless at this point. You can see the progression of usage here:

(Github Stats)

The intention is to get 1.1.8 shipped after the Metadoc launch, then immediately enter maintenance mode. This will also be the point where I will start coding the successor effort, code named "rt".

What is the future for this project?

The current plan is to replace NVM4W with a successor, code-named "rt", which emphasizes "runtime management". This will, with 99% certainty, be both an open source and commercial effort. Don't worry, the features that are free and open source today will remain that way. Nobody will be taking anything away. In fact, this change will likely produce a significant number of new features (like cross-platform support) and make the project more accessible to developers. The planned commercial offerings are add-ons, focusing on greater productivity, awareness, collaboration, and team/organization needs.

Go was originally selected for NVM4W so it could easily evolve to support macOS and Linux. The challenge with anything "not JavaScript" is the added difficulty it brings to a community of JavaScript developers. While the "rt" roadmap is not set in stone, there is a strong chance the open source utility will move to JavaScript. I've put effort into a project called author/shell, which was recently presented at OpenJS World 2020 back in June. This will likely evolve and be the basis of the "rt" CLI tool. We now have ways of packaging and deploying JS apps as small form binaries, which alleviates former concerns of relying on the presence of an existing runtime (i.e. needing Node to install Node never made sense).

The commercial add-on would be closed source.

I've always viewed version management as a small peekhole into a vastly bigger picture. However; to grow a project like this, it needs to be more than a side project. At this time, I believe a commercial venture is the fastest sustainable route to achieving this larger vision.

Ask questions!

Remember, I have alot going on above (as you can see above). However; I will try to answer questions here. I hope the NVM4W community uses this new discussion feature to help each other out. Please keep conversations about how to use the tool, npm, features, etc here. Use the issues for tracking bugs and technical problems.

2 replies

First time question. I am new to the Node and Angular environment. I am an experienced .net c# and vb developer with a new objective set by my employer to learn Angular. I am challenged with installing a specific version, specifically "nvm install 14.15.4".

I download the and hesitant in just running the nvm-setup.exe it contains.

Am I over thinking it.? After running the nvm-setup.exe file, does it contain all of the versions where I can open Cmdr or and using the command:, "nvm install 14.15.4"?

Thanks in advance for any help.


The nvm-setup.exe is just an installer. It is code signed and the entire app passes virus check suites. Once installation is complete, you can run nvm install x.x.x to install a version and nvm use x.x.x to switch to whichever version you want to run. You should be able to do most basic things in any shell, but only the terminal (command.exe) and powershell are "officially" supported. For the most part, other shells like cmdr will work, but some shells manipulate commands. There have been edge cases where something may not work as a result of something the shell does, but they're relatively rare.

If you're concerned about the contents of the nvm-setup.exe file, the alternative is to manually install. Instructions for that are available at YouTube also has videos about the installation process.

Welcome to Nodeland!

Answer selected by coreybutler

Question: does nvm-windows do something that changes the way npm help runs? I just noticed after running nvm install 12.16.1 and nvm use 12.16.1 that npm help npm returns No Results for "npm".

So I tried afterward installing node and npm on top of the version nvm installed using the msi from (I crossed my fingers hoping it would just overwrite what was in the c:\program files\nodejs symlink without without actually deleting the symlink and recreating a directory). It seemed to work fine and now npm help npm correctly launches the help file as expected.

7 replies

@marvhen Nice detective work... and that is a troublesome conclusion. Thanks for bringing it to my attention.


I’m not sure of the exact url...I just saw in the source code and was noting since it a different domain it is probably a different build config which includes docs.


I was asking because that's the same location where NVM4W pulls node from, but it pulls npm from the npm repo. Technically npm isn't a part of Node, but they do maintain versions since it ships with Node. I haven't checked to see if there is a difference in the version of npm pulled down from compared to the npm CLI repo.

Just to say thanks so much for your work on NVM-Windows. It has been very useful indeed. While I still like the speed and light weightness of Git 4 Windows bash with the native ports of some commands, I'm using WSL2 for more and more work.

0 replies

Just an update on "rt": I finally got a new Windows computer and am in the process of configuring my dev environment for work on the next version. The basic plan is already mapped out, but not setup as a proper project on Github yet. There are still several tasks to finish before I can start coding features, but the process has started.

2 replies

off topic : rt version means?


Yeah - that statement wasn't very clear!

rt is the name of the project that is slated to replace NVM for Windows. It stands for "runtime". In other words, it is the next iteration of version management.

My development schedule did not go as planned this year, so I've made adjustments.

First, NVM4W v1.1.8 will be released next week. I've merged 10 new PR's that resolve several long-standing issues and even add a few features. I didn't want to release this at this time, mostly because I cannot code-sign the application. The old certificates are expired and the cost is quite high for new certificates. However; Node 16.9.0 introduced corepack, which has new installation requirements. So, I will be releasing v1.1.8 without code signing the executable.

I am still hoping this will be the last release of NVM4W (succeeded by rt), but there may be another maintenance release before rt is available. Development of rt is moving along, though the time I spend on it at this stage is still building experiments.

0 replies

FYI, the link to author/shell has a typo.
Also, I'm not sure how different from the end-user perspective rt will be compared to nvs. I've switched from nvm4w to nvs because not being able to update npm without breaking things is very important for me. In most of my projects, I lock node and npm versions to avoid any inconsistencies. And sometimes npm version is not default for that node version.

7 replies

@Maxim-Mazurok Thank you so much for sharing!

For issue 300, that is specific to Node 8.4.x. More specifically, it is an issue with npm 5.x.x that ships with the Node 8.4.x family. I'm fairly certain all version managers suffer from that upstream bug. Outside of that, npm updates should work just like they would if you didn't have a version manager. That's not really a feature of version managers, it's a feature of Node.

I am experimenting with several automation strategies for installation/uninstallation, including the ability to find all node projects on a computer (environment discovery). I suspect this work will ultimately identify all the engines used. Frankly, the experiments are less about what gets installed and more about the balance between automation and user control.

NVM4W already supports proxies (both secure and insecure), but it requires manually configuring the endpoint. If I understand correctly, you're suggesting the proxy settings should be identified from the registry and automatically used? That seems like a good idea, especially if there were an option to turn it off (for those who don't want it to happen automatically).

Thanks again for sharing. It really means alot, and it's the best way to help me understand how folks want to use Node.


Regarding #300, indeed, it looks like npm upgrades work fine now... A few other inconveniences that I noticed now trying nvm from nvs, is that nvm doesn't use semver, so nvm i 16 would literally install 16.0.0, but nvs will treat it as semver and install the latest 16.x.x version.
Another thing I noticed is that nvm requires admin access. If you consider that I'm usually switching node versions in VS Code integrated terminal (which runs as non-admin) - this can be pretty inconvenient, having to switch to another window with cmd as admin.
I hope that this feedback will help with the new tool!


Thank you, the feedback is very much appreciated!

NVM4W does use semver. v1.1.7 and below did not support partial semver, but 1.1.8 does... i.e. nvm install 16 expands to nvm install 16.9.1 (or whatever the latest minor/patch version is at the time).

As for the admin privileges, rt already has support for optionally using junctions instead of symlinks (junctions do not require elevated administrative permissions). NVM4W currently only uses symlinks. Some other version managers use only junctions. nvs uses a shim, i.e. you don't run Node directly. This is the same practice the original nvm used, and it caused permission problems for thousands of users... i.e. they would run their code locally, not realizing they needed upgraded permissions to perform certain activities, or they would inherit the wrong environment variables (user, user path, etc.) in their code. I believe symlinks are the most technically appropriate way to pass control directly to the node executable (instead of using a shim middleman). Junctions provide similar support with some caveats, but without the permission requirements. Linux does not have the same permission requirements Windows does for symlinks. Recent Windows updates have started loosening the permission requirements for symlinks, so rt will default to using symlinks with an option/mode to use junctions for users who really need it (with a warning about the caveats).


I was trying 1.1.8 yesterday and 16 didn't expand. Not sure if I was using the install or use command. I've downloaded

Yeah, Linux all the way ;) I'm trying to use WSL whenever I can. The only issue that I didn't properly solve is running integration tests with non-headless Chrome in WSL, for some reason it only works as root.


It looks like the code expanding partial semver values only seeks the latest minor version, not the latest patch version. I thought that was resolved with a PR, but it looks like that code didn't end up working as expected (or I just chose the wrong PR... there were several). So, you may be experiencing an uncaught bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
7 participants