nvm not working in 32/64 bit situations for Windows 7

[corvinrok]

My Environment

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

• read the README to be aware of npm gotchas & antivirus issues.
• reviewed the wiki to make sure my issue hasn't already been resolved.
• verified I'm using an account with administrative privileges.
• searched the issues (open and closed) to make sure this isn't a duplicate.
• 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

I am running Windows 7 / 64 bit
I installed (with admin priv) the NVM for Windows 1.1.1. From there, I used

nvm install 6.1.0 all
nvm install 6.3.0 all

I then called
nvm list
resulting in

C:\Users\kagentes>nvm list
    6.3.0
    6.1.0

I then ran
nvm use 6.3.0 64

and then
node -v
and expected to get
v6.3.0

Actual Behavior

When running
node -v
I get

'node' is not recognized as an internal or external command,
operable program or batch file.

Also even after setting the nvm use command, I note the list does not seem to confirm the "use" command is working. As in:

C:\Users\kagentes>nvm use 6.3.0 64
Now using node v6.3.0 (64-bit)

C:\Users\kagentes>nvm list

    6.3.0
    6.1.0

From the screen shots in the https://github.com/coreybutler/nvm-windows page, I believe that the nvm list command should be returning something like this below (but I am NOT getting this)

C:\Users\kagentes>nvm list

*   6.3.0 (In Use)
    6.1.0

It does not have the asterisk or the "in use" indicator.

Possibly, this will also help diagnose the problem, but when I do the nvm arch command I get the following strange results, regardless of what I have set in nvm use:

C:\Users\kagentes>nvm arch
System Default: 64-bit.
Currently Configured: -bit.

Steps to reproduce the problem:

Steps to reproduce are already given in above expected behavior section. I already tried possible recommendations in other issues, such as Issue #146 , as well as restarting shell, restarting computer, and insuring everything was done with admin privileges. Before beginning all of this, I uninstalled previous versions of Node that was on the computer. (then installed nvm-windows and followed your instructions).

[coreybutler]

Sorry to ask the obvious question, but did you try restarting the terminal window? On Win7, sometimes it still chokes the first time you attempt to use a specific version (mklink).

[corvinrok]

Yes.. I did. I tried restarting the terminal window.. then even the machine.. neither changed the result.

[coreybutler]

OK - I'll look into this if I have time. Unfortunately, Win7 isn't something I often get around to.

[coreybutler]

To all, for reference regarding Win7: https://github.com/coreybutler/nvm-windows/wiki/Support-for-Windows-7-and-Earlier

[pleverett]

@kgentes - I will assume that before nvm you installed the 64-bit version of node, and installed nvm using the defaults.

After uninstalling node, make sure the directory where node was originally installed has been removed and not just empty. For Windows 7, 64-bit, the default is "C:\Program Files\nodejs".

If the "nodejs" directory still exists then the "nvm use" command can't make the symbolic link to the node version under nvm's control.

I had the same problem until I manually deleted the "nodejs" directory.

Hope that helps

[corvinrok]

Thanks @pleverett .. I will try that soon.. appreciate the heads up.

[corvinrok]

@pleverett THANK YOU SIR! This worked as you advertised! Superlike! This thread can be closed. Probably should be marked as a solution (not sure if that is something that can be done, here, I am new to this ecosystem) for future Windows 7 users who might run into this problem. NVM for Windows is working seamlessly now, once I removed the "C:\Program Files\nodejs" ("C:\Program Files (x86)\nodejs" for 32bit) directory that apparently doesn't get removed by default of the uninstaller. Along with that directory I also removed:
-- "C:\Users\username\AppData\Roaming\npm"
-- "C:\Users\username\AppData\Roaming\npm-cache"

Although that was probably not necessary.

Anyways, all is working. Thanks!

[corvinrok]

@pleverett @coreybutler

another related issue---
now that I can see and change versions of node via nvm , I wonder if I should be seeing different results when I do the :

npm config list

At the moment, none of the information except the one variable below changes.
user-agent = "npm/3.10.3 node/v6.3.0 win32 ia32"

all others stay the same. And it appears there is only one version of globally installed node modules.

if I am only changing from the 64bit version of 6.3.0 to the 32 bit version of 6.3.0, will I have the same global node modules installations? or will it make distinct ones? Or do I need to make a version change to get different set of globally installed node modules? Ideally, I would think it would keep a unique context for each bit version (because of native node modules like libxml-??? etc), but I can see why others might not like it to work that way.

Am I still using it wrong? or is this a related bug?

[corvinrok]

since this is still working on the same thread, I wanted to reopen this rather than create a new issue... [see previous comment for my updated status]

[coreybutler]

@kgentes - I'm sorry I missed this... it probably should be a different issue.

If you are only switching from 32->64bit or vice versa, NVM4W will use the same global node_modules directory. This was done intentionally, primarily to keep the overall footprint of the Node environment to a minimum. Having separate install directories for both 32/64 bit will double most users footprint... and the overall footprint is something most users don't even think about until they run out of space. Despite this, I am leaning towards using an individual installation directory by version+proc architecture anyway. It really should be up to the user, and as you said, this breaks some native packages.

I'm closing this since the subject is a bit different. Feel free to open a new issue if you like.