Nvm-windows: nvm root elevate.cmd: file does not exist

[Poltergeisen]

My Environment

• [ ] Windows 7 or below (not truly supported due to EOL - see wiki for details)
• [ ] Windows 8
• [ ] Windows 8.1
• [X] Windows 10
• [ ] Windows 10 IoT Core
• [ ] Windows Server 2012
• [ ] Windows Server 2012 R2

• [ ] Windows Server 2016

• [ ] My Windows installation is non-English.

I'm using NVM4W version:

1.1.7

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 (Have you tried version 1.1.0+?)
• [ ] 32 or 64 bit support (Have you tried version 1.1.3+?)
• [ ] Character escaping (Have you tried version 1.1.6+?)
• [ ] A standard shell environment (terminal/powershell)
• [ ] A non-standard shell environment (Cmder, Hyper, Cygwin, git)

Expected Behavior

Using nvm root C:\Git\nvm should set my nvm root to that folder. Then running nvm install 10.17.0 and nvm use 10.17.0 should work.

Actual Behavior

nvm root will set my root directory to the right place. But nvm use 10.17.0 is not working and is giving me the error exec: "C:\\Git\\nvm\\elevate.cmd": file does not exist:

Steps to reproduce the problem:

I had a previously existing version of node running. Our security team changed our virus scanners to be more restrictive in our appdata folders so I tried to move NVM into an excluded folder using nvm root C:\Git. Then I installed the version of node that I needed nvm install 10.17.0 and when trying to do nvm use 10.17.0 this happened.

[Poltergeisen]

Workaround:

Seems like re-installing nvm-windows into the root folder that I wanted fixed this issue. But this doesn't seem like the correct functionality.

[coreybutler]

When you say you had a version of Node installed, do you mean you had a prior version that was installed using nvm install or another standalone version installed? If I understand you correctly, you were expecting the versions previously installed with nvm4w to essentially be migrated to the new root directory. Is that accurate?

[Poltergeisen]

Yes I had Nvm installed correctly in a different root and when using Nvm root command I had expected it to migrate to the new location.

[coreybutler]

@Poltergeisen thanks for clarifying.

NVM4W doesn't currently move prior installations, but I think that's a reasonable expectation in this circumstance. I've marked this as an enhancement request.

[capsocrates]

What is the point of the nvm root command?

I have followed the same steps as Poltergeisen (albeit with a different path and versions of node). And I am seeing the same error. But I had no expectation that any existing node versions would be moved. I had no existing node versions. I did these steps

nvm root W:\nvm-root
nvm install 12.13.1
nvm install 12.14
nvm install 12.16
nvm use 12.13.1

And like Poltergeisen I got

exec: "W:\\nvm-root\\elevate.cmd": file does not exist:

But if nvm root [path] has no effect unless you install nvm into the chosen [path] in the first place, what is the point of the command?

[coreybutler]

@capsocrates The command is used more often in CI/CD processes where there are no existing installations. Consider running in a Docker container. Once the container boots, you can point to a mounted directory (i.e. a pseudo-dynamic directory).

After reviewing the code again, I am thinking there may be a bug (as originally described), because the elevate command really should move to the new root. I may have mistakenly jumped to a conclusion about permissions instead focusing on the file transfer itself. That would be the bug if I can confirm it. NVM4W will still not move the prior node installations by default... but having an option to do that seems like a reasonable enhancement request. I don't want to enable that by default because there are a lot of users whose environments are spread across mapped/remote drives. Moving global node_modules can mean transferring many GB across networks, which is really tough for users who aren't on the fastest networks (lots of rural school districts, municpalities, etc). Stil, I'm thinking there should be a flag so devs have a choice in the matter.

[capsocrates]

That use case makes sense and would explain why the current behavior is considered to "work."

For my part I don't care about transferring the existing installs as part of this command (though I'm sure it would be a nice option to have in a flag). But it would be nice if it worked as described :)