Nvm-windows: doesn't work with .nvmrc

[lewismoten]

My Environment

• [x] Windows 7 or below (not truly supported due to EOL)
• [ ] Windows 8
• [ ] Windows 8.1
• [ ] Windows 10
• [ ] Windows 10 IoT Core
• [ ] Windows Server 2012
• [ ] Windows Server 2012 R2
• [ ] Windows Server 2016

• [ ] My Windows installation is non-English.

  I have already...

• [x] read the README to be aware of npm gotchas & antivirus issues.

• [x] reviewed the wiki to make sure my issue hasn't already been resolved.
• [x] verified I'm using an account with administrative privileges.
• [x] searched the issues (open and closed) to make sure this isn't a duplicate.

• [x] made sure this isn't a question about how to use NVM for Windows, since gitter is used for questions and comments.

  My issue is related to (check only those which apply):

• [ ] settings.txt

• [ ] proxy support
• [ ] 32 or 64 bit support
  

  Expected Behavior

Same result as nvm use 4.4.4

Actual Behavior

Output: node v (64-bit) is not installed.

Steps to reproduce the problem:

created an .nvmrc file with 4.4.4 as the node version.
go to command line and run nvm use in the same folder as the file.

[coreybutler]

.nvmrc has never been supported. That's a feature specific to nvm, not NVM for Windows.

[inunotaisho]

@coreybutler I am from the Disaster Accountability Project and we have some developers who use windows and can't take advantage of the .nvmrc. We are starting to adopt nvm-windows for our volunteer web developers and I'd like you reconsider supporting .nvmrc. This is the site we use .nvmrc on.

[coreybutler]

@inunotaisho26 - Fundamentally, this project is focused on preparing Node as if it were installed the same way Node would be installed without a version manager. .nvmrc starts to get into specific environment management issues, which drastically increases the scope of the project. I see "environment management" being a fundamentally different problem than "version management". We've discussed these these different use cases in the the version management working group.

While this feature has been requested before, it is not something I have enough spare time to support. Due to the number of people who request general environment management solutions (beyond just .nvmrc), I am experimenting with ideas for a commercial environment management app to streamline these processes. The time requirements for supporting the community's large wish-list will require funding or sponsorship, so I'll probably lean on the infrastructure I've already built for Fenix. The catch: no ETA.

That said, see the roadmap. The "free" solution I've proposed is a hook system, similar to git's pre-commit, post-push, etc. This would allow developers to create their own scripts conducive for their own unique environments. Think of actions like post-install, pre-use, pre-execute, etc. This would enable users to write a hook script that looks for a .nvmrc file and switch the version on the fly.

[inunotaisho]

@coreybutler So basically two different approaches to installing multiple versions of node right?

[coreybutler]

Sort of. There are two different philosophies, but they're more about _using_ Node than installing it.

Philosophy 1: Native Use (Direct Process)
Node itself does not support .nvmrc. It just installs its own executable and npm. It's _used_ by directly running node.exe.

Philosophy 2: Augmented Use (Subprocess)
.nvmrc is a convention introduced by the original nvm project. Instead of calling node.exe directly, it uses a shim. The shim is responsible for configuring a pseudo-environment before passing commands to the node executable (i.e.. node is a subprocess of the shim). This is where the .nvmrc logic is processed. The catch, especially on Windows, is that node runs in the context of the shim, instead of the context of the user. This has a number of effects/challenges, such as not always passing appropriate credentials to the node subprocess (mostly around elevated permissions), slightly different environment variables, not always recognizing hard drive partitions (like a D:\ drive), and (in some cases) misrepesenting file paths (i.e. __dirname behaves unexpectedly) etc. These issues can be worked around, but they're compoinded when considering enterprise environment (Active Directory deployments, restricted desktops, SAN drives, etc).

General version management requires some level of shimming in order to prevent actually uninstalling/reinstalling node every time you need to switch a version (which would take forever). NVM4W aligns with the first approach by using symlinks to shim the installation _directory_, as opposed to option 2, which shims the executable. As a result, you're always running the node.exe executable directly, instead of running it as a subprocess..

[thany]

Small bump to this issue. Just ran into it.

It can't seriously be that hard. Here's what to do if a version is not supplied to nvm use:

1. Take version from .nvmrc
2. Is this version installed? If not -> install it
3. Is this version currently in use? If not -> use it.
4. Done

In other words, without version number specified, nvm use is a combination of nvm install < .nvmrc and nvm use < .nvmrc (pseudo command - won't actually work right now).

There's not much more to it.

[jeromemeichelbeck]

Small bump to this issue. Just ran into it.

It can't seriously be that hard. Here's what to do if a version is not supplied to nvm use:

1. Take version from .nvmrc

2. Is this version installed? If not -> install it

3. Is this version currently in use? If not -> use it.

4. Done

In other words, without version number specified, nvm use is a combination of nvm install < .nvmrc and nvm use < .nvmrc (pseudo command - won't actually work right now).

There's not much more to it.

I'm glad I'm not the only one having this issue...
Thinking of switching back to linux for developing :/

[coreybutler]

@thany @jeromemeichelbeck Feel free to fork the project and add this functionality yourself. I'll post a link here when it's ready.