Windows installer can corrupt its npm installation

[iarna]

• Version: All
• Platform: Windows
• Subsystem: Installer

The Windows installer copies the new distribution of Node.js in without removing the existing one. This can result in corrupted npm installations that either crash or result in unusual behavior.

This happens when a transitive dependency of npm has moved within its dependency tree. For example:

In Node.js 0.10.30 normalize-package-data is located at npm/node_modules/read-package-json/node_modules/normalize-package-data.

In Node.js 7.3.0 it is located at npm/node_modules/normalize-package-data.

If you install Node.js 0.10.30 and then install Node.js 7.3.0, you'll end up with normalize-package-data installed in both locations. Then when you run npm and it loads read-package-json then that will end up with the version of normalize-package-data that came from 0.10.30 and things won't behave as you expect. An easy way to test this is to create a package with the following package.json:

{
  "name": "@example/module",
  "version": "1.0.0"
}

and run npm install in the package directory.

You'll see an error that starts with:

npm ERR! install Couldn't read dependencies
npm ERR! Error: Invalid name: "@example/module"

It's worth also noting that this is only reproducible if you've never updated npm on your Windows system, as global modules on Windows are not installed in the same place the installer puts its copy. This means that when you update your Node.js on Windows you keep all of your existing user installed global modules including npm. This detail probably accounts for why reports of this are not more common then they are.

Obviously, using the wrong version of a dependency can cause all sorts of problems. The one above is one that I happened to have handy, but it's not alone.

This is one of the things stopping npm from shipping with a flat dependency tree. (The other thing was allowing folks to update npm on a stock Node.js 0.8 install, but maybe that isn't a concern any more. =p)

This will effect any installer that copies without removing the existing installation. We don't see reports from non-Windows users with this sort of problem so I suspect the other installers don't share this bug.

[Fishrock123]

It's the mac installer problems all over again! 😐

*hides*

[iarna]

@Fishrock123 Ah yeah maybe? TBH I don't remember if we actually fixed that? (Or was that just Homebrew's installer?)

[gibfahn]

cc/ @nodejs/platform-windows

[joaocgreis]

I cannot reproduce this. I tried with v0.10.30 to v7.3.0, both x64 on a Windows 7 VM, and the old files are removed. In fact, there is a very noticeable stage of "Removing files" during the installation of v7.3.0.

@iarna what version of Windows are you using? The installers you tried were x86 or x64? Can you make installation logs of both installations with msiexec /i <filename>.msi /l*v InstallLog.txt so I can compare with mine?

[iarna]

@joacgreis This was from user reports. I'll do my best to repro on my Windows desktop.

For reference, the OSX installer issue is: npm/npm#10166

Related issues: #10288 & npm/npm#10166 (and many, many others)

[joaocgreis]

I'll close this for now, has been inactive for some time and I couldn't find a problem with the MSI. Please reopen or comment if there's any new data to help us move forward.

@iarna if there are new reports of this, please ask for a install log (msiexec /i <filename>.msi /l*v InstallLog.txt), it is essential do diagnose this type of issues. And feel free to mention me!