Nvm-windows: Ability to use nvm to launch a specific version of node.

[tracker1]

Although one could use batch files for this, and just accept that the symlink will swap around... it would be nice if one could nvm (version) -run somescript or similar for executing npm scripts with a specific version of node... with everything after the -run passed to node as parameters... nvm 0.11.10 -run --harmony my-new-tool.js as an example.. because I'm moving towards doing new projects with 0.11 and older ones still on 0.10, it would be nice to be able to set my services to use the appropriate version.

[coreybutler]

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.

[mattheyan]

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.

[coreybutler]

@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.

[tracker1]

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.

[mattheyan]

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.

[coreybutler]

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.

[mattheyan]

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 :)

[coreybutler]

@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.

[jedmao]

PowerShell

nvm use $(Get-Content .nvmrc)

Bash

cat .nvmrc | nvm use

Command Prompt

Can't figure it out.

[nerdkid93]

@jedmao

Command Prompt

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

[rofrol]

for git bash this works

$ nvm use `cat .nvmrc`

[FredyC]

Regarding Powershell, I've tried adding this to my profile script to automate switching. It works, but there is a rather big downside that nvm use is not checking if the same version is already used and elevated prompt jumps in every time.

if (Test-Path .nvmrc) {
    nvm use $(Get-Content .nvmrc)
}

@coreybutler Would it be possible to add that check, even with some command line flag?

[coreybutler]

.nvmrc is not supported, so a check won't do any good. .nvmrc is a an nvm for unix concept (different project).

[FredyC]

@coreybutler That's not what I mean, you don't need to care about such file at all. What is needed is a check to nvm use and don't do anything if a specified version is currently selected. With that check in place and the small script above it's possible to mimic unix behavior fairly good.

Whenever I would open Powershell in a folder containing .nvmrc it would get switched to that version. I am aware it's not ideal, but it's surely better than to keep remembering version of Node for each project and manually switching it.

To add more context, I am using Visual Studio Code which has integrated Powershell terminal that always opens in root folder of the project. With that in place I can get NVM switch when I use that.

[coreybutler]

@FredyC NVM4W doesn't run when a script is run (i.e. node index.js), so I'm not entirely sure when a check like that would even happen. The nvmrc concept is based on the premise that node is shimmed (i.e. called through a wrapper utility). NVM4W doesn't work that way. When you run node.exe, you're actually running Node directly... not a wrapper.

Additionally, your example only works on systems with powershell, which is not necessarily available or installed on all versions of Windows. While a powershell implementation isn't difficult, it should highlight the fact there are all kinds of different Windows configurations to account for.

There have been alot of requests like this, focusing more on environment management than version management. The proposed solution is a hooks feature, currently on the v2.0.0 roadmap. This would allow developers to run whatever scripts they want in response to NVM4W events, similar to git hooks.

[FredyC]

Sorry, my explanation must be terrible if you are still not getting it :) Forget about .nvmrc, I don't expect NVM4W to do anything with that file.

What I am asking is simply extending nvm use command so it checks if the specified version is currently used and if its, it will just print message and exit. It can require optional command line flag for that. The current behavior is that it always tries to use a specified version causing a popup for elevated command.

Clear so far? I am not asking anything else from NVM4W. Reading .nvmrc file will be done outside of its scope. That file can be called whatever I like it for that matter.