You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow multiple installs of Node on Windows with msi #4603
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
...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.
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
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?
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.
@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 :)
@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?
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.
@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.
@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 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.
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.
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.
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.
Activity
felixfbecker commentedon Jan 11, 2016
Some comment wether this will get on the backlog or not would be nice
Fishrock123 commentedon Jan 11, 2016
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 commentedon Jan 11, 2016
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 commentedon Jan 11, 2016
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 commentedon Jan 11, 2016
@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 Filesand 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 commentedon Jan 11, 2016
@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 commentedon Jan 11, 2016
@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 commentedon Jan 12, 2016
it's built using the wix tools which is an open source msi creation tool.
orangemocha commentedon Jan 12, 2016
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 commentedon Jan 12, 2016
@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 commentedon Jan 13, 2016
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 commentedon Jan 13, 2016
Pinging some wix friends.
@giltayar @AdirAmsalem @bolshchikov any chance you could get someone from the wix tools team to look into this?
60 remaining items
felixfbecker commentedon Mar 15, 2018
@ljharb What is the argument against 3.c?
tniessen commentedon Mar 15, 2018
@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 commentedon Mar 15, 2018
Yeah, making the documenting the status quo is always good.
ljharb commentedon Mar 15, 2018
@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 commentedon Nov 11, 2018
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 commentedon Nov 11, 2018
@refack I don't agree that this is a
wontfixissue, we are simply still waiting for the version management group.refack commentedon Nov 11, 2018
Ack.
blockedis the proper label (IMHO it's onlywontfixWRT to the MSI)refack commentedon Nov 11, 2018
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 commentedon Nov 4, 2019
@ljharb Any updates on this?
tniessen commentedon May 9, 2020
@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 commentedon May 9, 2020
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.