This is something I've thought about, but haven't yet come up with an approach I feel is robust enough. I am also still pondering whether this is even appropriate for the tool or not, since it would extend the scope from being a simple installation/version manager into actually running node.

This introduces some foreign elements into the workflow.... for starters, node would be running as a subprocess of NVM for Windows. Since NVM for Windows is written in Go, node would be subject to some outlying constraints. For example, process.title = "My App"; would not work as expected because unlike Node, Go cannot change a Windows process name. There's also a need for piping stdout and stderr from the node child process to the Go process. Bottom line is you're not working directly with node, you're working with Node thru Go.

nvm and nodist have this feature, and I see value from a simplicity perspective... but I don't know if the quirks are worth it right now... one of the main driving factors that led me to create this project i nthe first place was to avoid quirks.

That said, I'm open to ideas because I do think this would make cherry-picking a version of node a trivial effort.

In the meantime, you could just type %NVM_HOME%\v0.11.14\node --harmony my-new-tool.js.

Edit: Sorry about rehashing this. I just realized that this issue was closed ;)

Maybe this is a bad idea, but I'll throw it out there...

What about instead of having %PROGRAMFILES%\nodejs on the path, have another folder with node.bat and npm.bat files. They would search for an .nvmrc file from the current working directory and call that version of node or npm directly if found, or fall back to %PROGRAMFILES%\nodejs if not. I know I'm glossing over some technical details but it _seems_ like that might be do-able.

Also, this wouldn't necessarily have to be a part of nvm proper, but it would be nice if it could be incorporated for convenience. It doesn't seem like this conflicts with nvm, and the majority of the value still remains in installing different versions of node and managing the symlink for the normal use cases.

Anyway, just an idea to consider.

@mattheyan - Using a batch file still means wrapping node, so there will still be quirks and incompatibilities. The only way to guarantee node will run as intended is to run node directly, not through a wrapper. Unfortunately, I tried this with node-windows and there have been more issues with wrapper workarounds than anything related to the project.

There are some interesting things happening with Go 1.7 that might, and I really stress the might, make this possible. However; that's still quite a ways from being released. I've been keeping my eyes on this for a while though (I would actually like to have this myself), and if a reliable solution becomes available, I'll definitely look into adding it.

A .cmd file should handle calling npm, or executing node with the appropriate stdin/stdout, as it's a pretty inherent part of windows... it actually sounds like an interesting idea.

Yeah, I was thinking it could work in most cases. Node on windows does utilize bat/cmd file redirects a lot it seems. @coreybutler I don't doubt these quirks you mention exist, but I'm curious to hear what kind you've seen and whether they're common use-cases or obscure edge cases. Either way I understand why it would give you pause incorporating in nvm. And, like I mentioned before, there are other technical hurdles to overcome. But, I do think it would be really valuable if it could be done, if not in nvm proper then maybe in a companion tool.

Well the process.title glitch I mentioned above is a big one from the node-windows community.

However; the most prominent issues crop up around the file system. There are typically a bunch of issues with __dirname and __filename, as well as process.cwd() or anything else related to relative directory paths. I've received 100's of questions about this. The "wrapper" executable (winsw in the case of node-windows) runs from a different directory than node is installed in, so resolving filepaths can (and often do) differ. These issues can be worked around, but it causes alot of headaches for folks when their app works in one place and not in another, seemingly for no apparent reason.

File system permissions can also be a challenge, as can passing in environment variables, all for the same reasons. When you wrap an executable, you're basically passing in a user to run it with too.

Remember, this project will no longer be Windows-only in the next release. In some experimentation within Docker, there have been other issues based on the file system. It has to do with how Docker is implementing volumes, so not directly an NVM4W thing, but I use it as an example of an emerging practice (containerization) that depends on an executable behaving the way it's supposed to.

When I initially released NVM4W, I exchanged a few thoughts with Sindre Sorhus, who maintains the awesome-node list. I tried to add both NVM4W and nvm to that list, but he objected to nvm (which uses a wrapper). The gist of it was too many people were experiencing glitches, so I'm sure there is stuff I haven't seen yet either.

Thanks for the insight @coreybutler. I must admit I don't fully understand the nature of these issues, but it sounds like you've experienced pain from this in the past, so I see why you'd be hesitant to do this. I may revisit this at some point as a separate tool, and maybe I'll run into the same issues when I do (in which case you can say "I told you so" :P).

Feel free to close this issue since I think it was closed when I rehashed it - I would but it doesn't look like I can. Thanks again for the info and thoughts :)

@mattheyan - If you do produce a companion tool, stay in touch. Like I said before, it is something I am also interested in. If there is a good companion tool, I'd certainly put up a link to it in the README here.

PowerShell

nvm use $(Get-Content .nvmrc)

Bash

cat .nvmrc | nvm use

Command Prompt

Can't figure it out.

@jedmao

Command Prompt

for /f usebackq %i in (`type .nvmrc`) do nvm use %i

for git bash this works

$ nvm use `cat .nvmrc`