Repository navigation
x64 Windows installer installs to Program Files (x86) #2951
Description
Activity
What version of Windows?
I'm running W10 and it installed perfectly.
Reacted by ssharifi02It 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, notC:\Program Files (x86)if it is a 64 bit version.I'm running Windows 8.1.
- addedwindowsIssues and PRs related to the Windows platform.Issues and PRs related to the Windows platform.installIssues and PRs related to installing Node.js and its installers.Issues and PRs related to installing Node.js and its installers.
on Sep 18, 2015 cc @nodejs/build @nodejs/platform-windows
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.
@orangemocha This is not the whole picture. I had a 64-bit installation previously.
@kleinfreund What happens if you uninstall everything and do a clean install?
- Uninstalling nodejs
- Deleting
%appdata%/npm,%appdata%/npm-cache - Removing node/npm path entries
- Installing with
node-v4.1.0-x64.msi(suggested installer path isC:\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%\npmis the location for global packages, not the node install directory. I wonder, shouldn't this be a thing of the past, too?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\foreverEven if I run as administrator. What exactly did you change to fix your problem?
@seishun When choosing to add the path entries during the installation process, two entries are added to the environment variable
path:- User-level variable
PATH:C:\Users\User\AppData\Roaming\npm - 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
npmthat is installed toC:\Program Files\nodejs\node_modules\npm. However doingnpm install npm -ginstalls to%appdata%\npm. After updating npm, thenpmcommand 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
.npmrcwith the following:save-prefix = ~ prefix=${APPDATA}/npm proprietary-attribs = falseIs that potentially harmful here?
- User-level variable
@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?
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.
@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.
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.
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.
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.
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-x86and then upgrade tov0.12.7-x64it will suggest the previous install path, the default is underProgram Files (x86). When you installv4.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 npmwas also fixed recently and shipped with v4.0.0.C:\Program Files\nodejs\npm.cmdis 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
.npmrclooks fine. For reference,C:\Program Files\nodejs\npm.cmdshould be like this and not like the old version.@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 -vresulting in 2.14.3.@kleinfreund What is the output of
where npm npm prefix -g node "C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js" prefix -gand what are the contents of the files
C:\Program Files\nodejs\node_modules\npm\.npmrc C:\Program Files\nodejs\node_modules\npm\npmrc?
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
@kleinfreund I noticed that you are using
MINGW64. Can you try thenpm -vin the Windows Command Prompt just to be sure?When you run
npm, the Windows Command Prompt will usenpm.cmd, where the fix is. I also fixed thenpmscript for Cygwin here, but not for other shells. I'll see what I can do about that!@joaocgreis Behavior is indeed different. As you described,
npmin cmd.exe will output 3.3.3 in both cases.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.
- addedgood first issueIssues that are suitable for first-time contributors.Issues that are suitable for first-time contributors.and removedgood first issueIssues that are suitable for first-time contributors.Issues that are suitable for first-time contributors.
on Mar 15, 2016
The current Windows installers will install nodejs to
C:\Program Files (x86)\nodejsalthough the downloaded file isnode-v4.1.0-x64.msi. Previous versions would install toC:\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.