x64 Windows installer installs to `Program Files (x86)`

[kleinfreund]

The current Windows installers will install nodejs to C:\Program Files (x86)\nodejs although the downloaded file is node-v4.1.0-x64.msi. Previous versions would install to C:\Program Files\nodejs.

This can cause small troubles when one already has path environment variables configured and chooses to disable doing so during the setup.

[tflanagan]

What version of Windows?

I'm running W10 and it installed perfectly.

[kleinfreund]

It installs just fine and upon fixing the conflict between my path variables (32 bit vs 64 bit), the command line reports the correct node and npm versions. However the installer should install to C:\Program Files, not C:\Program Files (x86) if it is a 64 bit version.

I'm running Windows 8.1.

[Fishrock123]

cc @nodejs/build @nodejs/platform-windows

[orangemocha]

This happens when upgrading from a 32-bit installation. Workaround: uninstall and do a clean install.

This is fixed for new installations but if at a certain point we want to avoid this situation we need to break with the old and require a clean install.

[kleinfreund]

@orangemocha This is not the whole picture. I had a 64-bit installation previously.

[seishun]

@kleinfreund What happens if you uninstall everything and do a clean install?

[kleinfreund]

1. Uninstalling nodejs
2. Deleting %appdata%/npm, %appdata%/npm-cache
3. Removing node/npm path entries
4. Installing with node-v4.1.0-x64.msi (suggested installer path is C:\Program Files\nodejs\)

Node.js is now installed in the correct location.

However, I still need to move the path part for node from the system to the user level so %appdata%\npm is the location for global packages, not the node install directory. I wonder, shouldn't this be a thing of the past, too?

[seishun]

It installs into %appdata% for me.

C:\Users\Nikolai>npm install -g forever
npm WARN optional dep failed, continuing fsevents@0.3.8
C:\Users\Nikolai\AppData\Roaming\npm\forever -> C:\Users\Nikolai\AppData\Roaming\npm\node_modules\forever\bin\forever
forever@0.15.1 C:\Users\Nikolai\AppData\Roaming\npm\node_modules\forever

Even if I run as administrator. What exactly did you change to fix your problem?

[kleinfreund]

@seishun When choosing to add the path entries during the installation process, two entries are added to the environment variable path:

1. User-level variable PATH: C:\Users\User\AppData\Roaming\npm
2. System-level variable PATH: C:\Program Files\nodejs

Since the installation directory of node is added to the system-level, it appears before the entries of the user-level path variable. That leads to running npm that is installed to C:\Program Files\nodejs\node_modules\npm. However doing npm install npm -g installs to %appdata%\npm. After updating npm, the npm command being executed is still the one from the installation directory.

To workaround this I moved to second entry from above to the user-level as well and put it behind the entry for npm. This way, the correct npm version is executed.

Edit: I just noticed that I have a .npmrc with the following:

save-prefix = ~
prefix=${APPDATA}/npm
proprietary-attribs = false

Is that potentially harmful here?

[seishun]

@kleinfreund This is unrelated to x64, and it's well-described here: https://github.com/npm/npm/wiki/Troubleshooting#upgrading-on-windows

But let's get back on topic. Do you have any guess under which conditions the installer suggests the wrong installation path?

[kleinfreund]

Well, it's weird. I can't think of anything that makes sense. Before I did the reinstall as suggested, the situation was different in the sense that a) previous node was still installed and b) the path wasn't cleaned up.

[seishun]

@nodejs/build @nodejs/platform-windows I think we should close this until someone figures out how to reproduce this. Otherwise we can't really do anything about it.

[orangemocha]

If I remember correctly, this happens when upgrading a previous 32-bit installation. If you upgrade from 32-bit to 64-bit, and then from 64-bit to 64-bit, you will also be left with the same installation path, so the problem perpetuates itself until you do a clean install.

@joaocgreis and I were discussing this recently. The 'right' fix would be to have new separate upgrade codes for 32-bit and 64-bit. but that would mean requiring a clean installation.and breaking upgrade ability from a certain version on. This is quite confusing and so I am inclined to say that the issue still needs some attention. Perhaps we just need to bite the bullet and force the clean install in the next semver major release.