Per Script Shell Versions
The ability to run a specific version for a specific script/command, such as nvm run x.x.x script.js is frequently requested. There is no plan to support this natively. However; I am planning to add features that will
allow developers to mimic this functionality on their own.
First, think about what the computer is being asked to do. "Hey computer, install Node.js for just this one execution, then reinstall whatever version I had before. Oh, I may want you to also uninstall/reinstall another version in another shell, then switch back. Handle all of the npm functionality while you're at it, and the many GB of modules I have installed." When you think about it from that context, it's fairly clear that what developers really want in this circumstance is environment management, not version management.
Doing this requires a shim or alternative executable. Projects like nvm (for Linux) use a shim. In other words, it calls a file named node, but it's actually running a shell file that turns around and runs the actual node executable. It's a bit like a mask. The major issue with this, especially on Windows, is the fact it can change the user context and the parent process. Using a process to run another process means you have to pass the context of a user from one process to another. Windows users don't always have permissions to do this (think Active Directory environments with locked down permissions). The bottom line is there is alot of black magic happening... you think you're running Node, but you're not actually running it directly. In my experience, this creates more problems than it's worth.
There is a more appropriate technology for environment management: containers. There are far more considerations in managing an entire environment than there are managing which version of software is installed on a system. The containerization movement has already addressed these considerations at very deep levels. After all, an entire development discipline/industry has sprouted from the use of container architecture (think Docker).
Philosophy:
I don't intend to recreate the Docker wheel. NVM for Windows is designed for version management, and that's where it will stay. Other version managers attempt to manage the entire environment, which means they have to address all of those issues... and doing it right means considering far more than just Node.js. It's a non-trivial team effort, which is not sustainable for an open source project that receives no funding (seriously, out of 1.2M users, the Patreon account gets $10/mo).
That said, there is a clear and present community desire for environment management. To address it, I am attempting both open source and commercial strategies to support these demands.
Open Source Roadmap
I've been working on iterations of this software, testing (privately) for quite some time now. I still feel strongly that one of the best features to build in the next version is a hook system. By supporting hooks (similar to how git does it), developers are free to run scripts in response to system activities/actions. It is the developer's responsibility to make it work in their unique environment. This provides greater flexibility for developers and less strain on the team (of one guy) supporting this project.
As mentioned above, environment management is more complex than version management. There are tools (like Docker) that do environment management well. However; the sheer existence of these tools does not mean the workflow (i.e. how you use it) is as streamlined or as intuitive as software authors would like. The point: I've heard the community's desires/requests and I see validity in the use cases people have presented. I share the same struggles many of you do, and I feel the same pains. I've spent several years researching the workflow marketplace, speaking with developers, companies, investors, and presenting new workflow ideas. I'm also sitting on a slew of software in the "proof of concept" state... all in an effort to help make developing software a more enjoyable and concise experience.
I have intentions and traction in building an environment management application, specifically addressing the workflow challenges of authoring software. This effort must be commercial, because software of this caliber can't be built without financial backing. The required time commitment is simply too high. This project has already suffered from "I have to pay the bills, so time is spent on consulting instead of OSS software dev". To forge ahead, I've launched a company (Author.io) to support future development. NVM For Windows will still exist and remain open source.... but we'll be addressing more complex development needs through different software. We're about 2yrs into development of the supporting infrastructure and we've produced a significant amount of code that is or is in the process of being open sourced. The NGN, chassis, web components, and metadoc efforts are all nearing completion. Our first desktop release is Fenix Web Server 3.0.0, which is built on all of these technologies.
The goal is not to undermine NVM for Windows. It's to assure the scope of features and support is something that's actually maintainable under an open source model. We don't want anyone to feel like we're forcing them into paying for software, so NVM4W will continue to receive updates, new features (within the scope of version management), and ultimately remain separate from our commercial endeavors. The value we're adding through commercial efforts will be focused on workflow and development experience. Our hope is the commercially supported efforts will free us from the consulting grind we're currently in, allowing us to focus more time actually working on the open source code.