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.

[seishun]

If I remember correctly, x64 installers have been around forever, so I don't see why this would become an issue only now.

Is there anything that an upgrade does that a clean install doesn't? If not, then forcing a clean install seems like the correct solution.

[orangemocha]

Upgrades and clean installs are equivalent.

This issue has indeed been around forever. We made a fix recently, that is now in all the latest releases, that solves the problem on clean installs. Before that fix even if you did a clean install of 64-bit after 32-bit, you would get suggested the wrong path.

My concern with forcing a clean install would be that it could break any scripted deployments out there that rely on upgrade ability. I think a semver major release would be the best time to do it, as people already expect things to potentially break in those and we would have a chance to message it properly.

All in all, I think we need to go back to the drawing board on this issue, so I would keep it open for now.

[joaocgreis]

About the installation:

For old versions, when upgrading, they always suggested the old installation path. We changed it to ignore it and suggest the default path when upgrading from 32 to 64 (there are no v0.x releases with it yet). Therefore, if you install v0.12.6-x86 and then upgrade to v0.12.7-x64 it will suggest the previous install path, the default is under Program Files (x86). When you install v4.1.0-x64, it is a 64 to 64 upgrade, so it will suggest the same. Possible fixes already mentioned above by @orangemocha . Uninstalling and installing instead of upgrading will (hopefully) clean the registry entries and work ok.

About npm:

The path seems correct, first the system path and then the user path. npm install -g npm was also fixed recently and shipped with v4.0.0. C:\Program Files\nodejs\npm.cmd is always run, but it looks for an updated version of npm and runs it instead if found. After installing v4.1.0, I get this:

C:\Users\Administrator>npm -v
2.14.3

C:\Users\Administrator>npm install -g npm
C:\Users\Administrator\AppData\Roaming\npm\npm -> C:\Users\Administrator\AppData
\Roaming\npm\node_modules\npm\bin\npm-cli.js
npm@3.3.3 C:\Users\Administrator\AppData\Roaming\npm\node_modules\npm

C:\Users\Administrator>npm -v
3.3.3

@kleinfreund your .npmrc looks fine. For reference, C:\Program Files\nodejs\npm.cmd should be like this and not like the old version.

[kleinfreund]

@joaocgreis I cannot confirm that it works that way. When I put the node entry back to the system path, I only get v2.14.3. I rerun the exact commands as you did with only the last npm -v resulting in 2.14.3.

[joaocgreis]

@kleinfreund What is the output of

where npm
npm prefix -g
node "C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js" prefix -g

and what are the contents of the files

C:\Program Files\nodejs\node_modules\npm\.npmrc
C:\Program Files\nodejs\node_modules\npm\npmrc

?

[kleinfreund]

@joaocgreis

Philipp@RAUMSTATION MINGW64 ~/dev/repos
$ where npm
C:\Users\Philipp\AppData\Roaming\npm\npm
C:\Users\Philipp\AppData\Roaming\npm\npm.cmd
C:\Program Files\nodejs\npm
C:\Program Files\nodejs\npm.cmd

Philipp@RAUMSTATION MINGW64 ~/dev/repos
$ npm prefix -g
C:\Users\Philipp\AppData\Roaming\npm

Philipp@RAUMSTATION MINGW64 ~/dev/repos
$ node "C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js" prefix -g
C:\Users\Philipp\AppData\Roaming\npm

Philipp@RAUMSTATION MINGW64 ~/dev/repos
$ cat "C:\Program Files\nodejs\node_modules\npm\.npmrc"
cat: C:\Program Files\nodejs\node_modules\npm\.npmrc: No such file or directory

Philipp@RAUMSTATION MINGW64 ~/dev/repos
$ cat "C:\Program Files\nodejs\node_modules\npm\npmrc"
prefix=${APPDATA}\npm

[joaocgreis]

@kleinfreund I noticed that you are using MINGW64. Can you try the npm -v in the Windows Command Prompt just to be sure?

When you run npm, the Windows Command Prompt will use npm.cmd, where the fix is. I also fixed the npm script for Cygwin here, but not for other shells. I'll see what I can do about that!

[kleinfreund]

@joaocgreis Behavior is indeed different. As you described, npm in cmd.exe will output 3.3.3 in both cases.

[rofrol]

Just set %USERPROFILE%\AppData\Roaming\npm to be at the beggining of %PATH%. Then verify it:

$ echo -n $PATH | tr ':' '\n'

It's not needed in cmd.exe though.