Allow multiple installs of Node on Windows with msi

[felixfbecker]

It should be possible to install different Node versions to different directories with the msi. Actually, many programs like Java JDK, MySQL Server, PostgreSQL or Python version the installs by minor releases by default. It should at least be _possible_ (if not the default) to install Node versions like this

C:\Program Files\NodeJS\4.0
C:\Program Files\NodeJS\5.4

...but the installer either errors or uninstalls the previous version, depending on order of install. People should be allowed to install to whatever location and these separate installs should be uninstallable separately from Control Panel (with their version in the name). The installer should simply have a checkbox (next to "Add to PATH") to uninstall the previous version for easy upgrades.

[felixfbecker]

Some comment wether this will get on the backlog or not would be nice

[Fishrock123]

Not many people work on the installers in general, if you feel strongly about this you may have to work on it yourself. :) I'm not very familiar with the installers (especially windows) but I can try to help/point to the right people.

I'm not familiar enough with windows installations to tell if this is actually a good idea though. cc @nodejs/platform-windows

[MylesBorins]

My main concern with something like this would be how a system would handle multiple installs in the path. is it only the most recent that is linked to? It seems like this could be a breaking change for systems, but I don't really know the installer so this is speculation.

@felixfbecker is there a reason you prefer this to be handled by the node installer rather than a userland module such as nvm-windows?

[cjihrig]

I'm not saying that the installer shouldn't handle these cases, but for the time being, you'll likely have a better experience if you use a version manager like nvm-windows, as @thealphanerd mentioned.

[felixfbecker]

@thealphanerd It is pretty easy to configure whats in the %PATH% on Windows, there is a very nice GUI for it:

(You can see how I installed 5.4 in a versioned directory, but I cannot install a second version next to)

People can either set for themselves what version should be there or just check "change PATH" when they install a new version, the old entry should then get replaced by the new one.

The msi is the primary and recommended installation method for Node on Windows, and just how programs are installed on Windows. Even NPM says under how to install to Windows "get the msi, npm is in it". msi is for Windows what pkg is for Mac. Version managers bypasses the native installation methods on Windows, you don't get an entry in control panel for uninstalling, you dont get shortcuts in start menu, etc. They dont share global NPM packages between versions, create symlinks and switch their targets, download node versions in AppData directories so it does not need administrative rights etc to solve a problem that shouldnt exist in the first place. I want my programs to be installed in Program Files and uninstallable via Control Panel, and I should be able to install as many versions of this in parallel as needed. I can then set my PATH to the newest one or whatever I need the most often and when I need another version, I can just reference the full path. And if I want, I can download a new msi and install it from the command line - no need for version managers (I havent tested this with Node, but most msis allow you to do so).

@Fishrock123 I indeed feel quite strongly about this: Everyone respects how files should be layed out on Unix file hierachy and everyone is ok with needing sudo to do stuff, but on Windows often the motto is install anywhere, avoid UAC at all cost. To often you see "just download the zip and put it in C:" or installers like Squirrel that dont allow you to customize the install location.

Unfortunately, I have never worked with installers before. I will try to take a look at it. But from what I understand, at least noone is opposed to this :)

[MylesBorins]

@felixfbecker thanks for sharing! I definitely think that this could be a big improvement to the windows workflow!

Let us know what we can do to help support you as you dig into this problem

[felixfbecker]

@thealphanerd @Fishrock123 I found out that the stuff is located under tools\msvs\msi, but the solution file requires VS 2010 (I have 2015). Is there a reason for this? Do I have to install VS 2010 to hack on this?

[cicorias]

it's built using the wix tools which is an open source msi creation tool.

[orangemocha]

This is something that I have been recently looking into and discussing with @joaocgreis. I agree in principle that the MSI installing only one version is too limiting. The issue of adding multiple versions / creating conflicts with the global PATH is probably the single biggest complication as already mentioned.

Python allows side-by-side installation of different major versions. That can be simply implemented by changing the upgrade code with each major version. Python also add a launcher to the path (py.exe, pyw.exe) which then select a particular version of the engine based on a shebang line in the script (or other default configuration). I am considering implementing something similar for Node.

[felixfbecker]

@orangemocha Why make it so complicated? Just give the user the choice to overwrite an existing PATH entry on install. Uninstalling previous versions would be the default anyway, so people who install multiple versions should know what they are doing. It's easy to detect what version is currently in PATH by doing node -v, and like I said it is easy to switch PATH settings on Windows manually.

The point with python was really the problem that there is a huge gap between Python 2.x and Python 3.x. I would like to not limit this on major versions, but minor by default with a directory structure like in my original post. But people could also install patch versions by changing the install dir.
I dont think shebang is needed as there isnt even a concept of shebangs in Windows. package.json provides a wonderful way to match supported Node versions for a project with all semver goodness. And if you use pm2 for example, you can specify the node runtime with an absolute path to a specific version.

[felixfbecker]

I read a bit about WiX and tried to understand the code but I don't think I'm able to contribute here. Sorry.

[benjamingr]

Pinging some wix friends.

@giltayar @AdirAmsalem @bolshchikov any chance you could get someone from the wix tools team to look into this?

[giltayar]

@benjamingr - those are two different Wix-es. The Wix you're referring to is a developer tool for building msi-s. The wix we are part of is a Consumer Saas for building web sites.

[giltayar]

Having said that, doesn't nvm work on Windows?

[benjamingr]

Oh oops, my bad - you guys are working on so many things related to web technologies I just assumed that it was the same company. Apologies Gil Adir and Sergey.

[giltayar]

I just googled nvm windows, and got this: https://github.com/coreybutler/nvm-windows

[orangemocha]

At the moment nvm for Windows is the best tool that I know of to run multiple versions on the same machine.

Just give the user the choice to overwrite an existing PATH entry on install.

I am concerned that this could introduce some problems / confusion based on the order of installs and uninstalls. I can't say for sure until we test it thoroughly.

The point with python was really the problem that there is a huge gap between Python 2.x and Python 3.x. I would like to not limit this on major versions, but minor by default

Major versions of Node als have many differences between them. They are major versions - by definition - because they introduce breaking changes. Minor upgrades within the same major are supposed to be backward-compatible. In light of that, majors seem like a good place to change the upgrade code. But if we had a solid side-by-side story, and a valid reason to, we could get more granular than that.

[cicorias]

If we can work out the aspects of how the PATH gets presented to the process along with the NPM pairing (as today they're in the same location/PATH) I can certainly handle the wix tooling / msi creation.

I do agree NVM for windows would be ideal as well, although the way that works today is via a symbolic link that switches it for any process that runs after the "use" version is issued. Not sure that's the desired approach.

Ideally, something that would allow side-by-side of 2 process simultaneously using version A and version B along with a paired version of NPM (and perhaps global NPM modules0.

Looking back to the opening comment on this issue, is this reasonable, with NPM/node_modules dangling off each path (duplication is OK?) - eg. if you switch versions, any global NPM modules would need to be installed again.:

C:\Program Files\NodeJS\4.0
C:\Program Files\NodeJS\5.4

[felixfbecker]

@cicorias The situation that NPM and NodeJS, despite having independent versions, laying in one folder by default is of course troubling. It is only the npm executable though - the global modules are always in %appdata%\npm. This is kind of weird, because while on Linux I believe global modules are truly installed globally (for all users) and need sudo, while on Windows, it's only for the current user and does not require "run as admin" (which creates its own problems, for example npm global modules can only be added to the path for the current user). I don't know if that is actually a problem - as far as I know, when I currently upgrade my Node version, my %appdata%\npm and therefor my global modules is left untouched.

Does it impose any problems, when the global modules are shared between versions (as they are right now), besides that engine constraints might get violated?

One option of course would be to install NodeJS and NPM in separate folders:

C:\Program Files
 |-- NodeJS
 |   |-- 4.0
 |   \-- 5.4
 \-- NPM
     |-- 3.3
     \-- 2.14

But npm itself is only an npm module, and the handling on Windows always caused trouble with self-updating npm. Another option would be to simply add the global npm module path to the PATH and put npm in there as a global module? That way everyone would be able to self-update with npm install -g npm or install any version independently of Node with npm install -g npm@2.14 (just like you can on any other OS).

Global modules should actually only be installed to ~\AppData\Roaming\npm if npm/node was installed locally to ~\AppData\Local. If they are installed globally to C:\Program Files, then the global modules should be in C:\ProgramData\NPM - and ProgramData doesnt even require admin rights (does this belong here or should I open an issue at the npm repo?). Anyway, either global modules would simply be shared by all node / npm installs, or the global modules directory needs to be versioned too:

C:\ProgramData\NPM\2.14
C:\ProgramData\NPM\3.3

[felixfbecker]

Is somebody working on this?

nvm is not really a solution. It allows you to switch between versions, but not have multiple versions side-by-side.

[giltayar]

True, but the switch is per-shell, so in essence, it does run multiple
versions side by side.

On Sun, Jan 24, 2016 at 1:02 PM Felix Becker notifications@github.com
wrote:

Is somebody working on this?

nvm is not really a solution. It allows you to switch between versions,
but not have multiple versions side-by-side.

—
Reply to this email directly or view it on GitHub
#4603 (comment).

[felixfbecker]

@giltayar AFAIK the switch is not per shell. It switches the target of a symlink in C:\Program Files\nodejs to different directories.

[giltayar]

I use nvm on the Mac, and it is *definitely *per-shell. Not sure about
Windows, though.

On Sun, Jan 24, 2016 at 1:24 PM Felix Becker notifications@github.com
wrote:

@giltayar https://github.com/giltayar AFAIK the switch is not per
shell. It switches the target of a symlink in C:\Program Files\nodejs to
different directories.

—
Reply to this email directly or view it on GitHub
#4603 (comment).

[felixfbecker]

See https://github.com/coreybutler/nvm-windows:

As a result, NVM for Windows maintains a single symlink that is put in the system PATH during installation only. Switching to different versions of node is a matter of switching the symlink target. As a result, this utility does not require you to run nvm use x.x.x every time you open a console window. When you do run nvm use x.x.x, the active version of node is automatically updated across all open console windows. It also persists between system reboots, so you only need to use nvm when you want to make a change.

I could certainly build my own version manager by downloading the node.exe binaries, placing them in C:\Program Files\<version>, and do

path C:\Program Files\NodeJS\<version>;%PATH%

or

Add-PathVariable C:\Program Files\NodeJS\<version> -Prepend

in a shell to switch versions (or just reference the full path). But then I would not get the benefits of the msi (npm and uninstalling from control panel / package control)

[benjamingr]

Oh cool, great to know this is possible @felixfbecker although it's hacky. Although personally I don't install node from the installer I can see the appeal.

If you're interested (are you?) - what would you need in order to be able to start working on a PR?

[felixfbecker]

@benjamingr Yeah it is hacky, especially because you have to install npm manually. That means

• downloading the npm zip from Github releases and extracting
• Inside extracted npm release, open an admin prompt and run node cli.js install -g npm

After that, global modules will be installed to where your node binary was, so C:\Program Files if you installed for all users (which means --global installs need admin rights). If you placed the node binary in %USERPROFILE%\AppData\Local\NodeJS\<version>, you don't need admin rights. Global modules, including npm itself, will not be shared across versions because it cannot be assured that they are compatible with other node versions. This is what I would be going for for the msi.

I am interested, but I don't have any experience with Wix or C++. Maybe you can tell me

1. What do I need to build / test the installer
2. In what files is the current behavior defined (canceling install if there is already a version)

[ljharb]

I don’t think anyone disagrees that we should do it; but it shouldn’t be done without a comprehensive plan - and “let’s do a one-off implementation on each platform” isn’t quite what I’d call comprehensive.

[garrettXCIV]

Of course. I didn't ever say we shouldn't have a solid plan for how to implement it on each platform because I completely agree that we should. I'd just like to see some progress.

[marcelklehr]

Sooo, I'm thinking:

1. Side-by-side installation isn't supported, but unintentionally enabled by the official way to install node on windows (i.e. the current MSI)
2. people probably do it anyway (not using MSIs though, as that doesn't seem to work, per OP, which is consistent with the notion that it's not supported officially)
3. Either we
   a. specifically advertise the MSI with the note that it isn't recommended if you need multiple versions side-by-side, because you'll need to do things that are not part of any official guide (it obviously would be nice to list some version managers as an alternative here :) )
   b. officially provide a zip along with an explanation on how you can do side-by-side installation, so that there is an official way to do it which works
   c. work on improving the MSI to intentionally support side-by-side installation, preferably in a way that is compatible with other version managers (i.e. any "standards" we opt to declare in this WG)

Is this a good summary?

Actually, none of the points in 3. are contradictory, and I happen to (intentionally) support all of them.

[ljharb]

There's also 3.d., which is find a way to prevent side-by-side installation with MSIs, while an official solution is worked on.

[ljharb]

Also there's 3.e, which is, do nothing while we work on a proper official solution.

[tniessen]

This dicussion has been ongoing for two years, so I am definitely in favor of 3.c. As a short-term solution, 3.b. (and possibly 3.a.) appear appropriate.

[ljharb]

I think 3.a. is a good idea; I'm very much against both 3.c and 3.b.

[jpeck17]

Your reading my mind rock on bro..

[fhinkel]

ping @tniessen @ljharb @marcelklehr

Do you think we can get consensus for 3.a and move this forward?

[felixfbecker]

@ljharb What is the argument against 3.c?

[tniessen]

@fhinkel I won't stand in the way, if someone were to open a PR saying that it is currently not supported / recommended, I would likely approve it.

It's been some time since I used the MSI, but as far as I remember, the current behavior is to prevent side-by-side installation, isn't it?

@felixfbecker See #4603 (comment), #4603 (comment), #4603 (comment). Summary: We should not work on a Windows-specific solution until the version management working group has come up with a "comprehensive plan". This has been open for two years now, any news from that WG?

[felixfbecker]

I won't stand in the way, if someone were to open a PR saying that it is currently not supported / recommended, I would likely approve it.

Yeah, making the documenting the status quo is always good.

[ljharb]

@felixfbecker I don't think we should do any work to support multi-version scenarios until the version management group has ironed out what that will look like.

@tniessen we don't yet have a plan; i just met with the build WG recently and confirmed the direction for a first step. I"m hoping to have time to write something up soon.

[refack]

I believe the current consensus is this is incompatible with the current MSI implementation.
Could be unblocked in the future with a new installer.

Put into https://github.com/nodejs/node/projects/13 backlog

[tniessen]

@refack I don't agree that this is a wontfix issue, we are simply still waiting for the version management group.

[refack]

I don't agree that this is a wontfix issue, we are simply still waiting for the version management group.

Ack. blocked is the proper label (IMHO it's only wontfix WRT to the MSI)

[refack]

BTW I've put it on the new backlog with the intent to make it visible to anyone who wants to pick this up.

[tniessen]

This seems like something the version management working group should handle, and also something that core should either handle on all platforms at once holistically, or by adopting a suite of existing tools to cover all platforms (this approach was rejected), or not at all.

@ljharb Any updates on this?

[tniessen]

we don't yet have a plan; i just met with the build WG recently and confirmed the direction for a first step. I"m hoping to have time to write something up soon.

@ljharb I believe this was two years ago, any updates? This issue has been open for four years, and the situation doesn't seem to have changed at all.

[ljharb]

This issue isn’t open.

No, there are no updates; the longer term plan is to standardize on install locations, but the node official installer still would not allow multiple installs directly - you’d have to go to userland for that.