Windows installer automatically uninstalls previous (LTS) version

[veganaize]

• Version: v14.12.0
• Platform: 64-bit Windows 8.1 (6.3.9600)
• Subsystem: Installer (Windows)

What steps will reproduce the bug?

1. Install Node.js LTS (v12.18.0) to default installation folder.
2. Install Node.js Current (v14.12.0) to a different folder.

How often does it reproduce? Is there a required condition?

It automatically happens during installation on Windows.

What is the expected behavior?

I expect it NOT to uninstall (or at least ask me if I want to uninstall) the currently installed LTS version.

What do you see instead?

The LTS version and its installation folder are completely removed from the system, without warning.

Additional information

The existing behavior doesn't allow me to temporarily install the latest/current version, on an LTS based system, in order to see if an issue has been corrected -- before reporting a bug.

[Trott]

Not commenting one way or another on the validity of the issue, and I might be telling you something you already know, but if you want a quick solution, you can consider a Windows-compatible version manager like nvs or nvm-windows.

[Trott]

@nodejs/platform-windows @nodejs/build

(We need more focused teams to ping for the installers, I suspect.)

[richardlau]

For some history, side by side installs has been previously requested, #4603. There is (was?) a version management group to look at how Node.js gets installed and their discussion on this is recorded in nodejs/version-management#16.

[Trott]

There is (was?) a version management group

That would be @nodejs/version-management. I thought they were for version managers, and not the installers that we create, but even if that's so, it's certainly all tied together....

[ljharb]

Indeed, the group is not for the installers, that's the build or release groups i think?

Currently, the supported node installers always and only install a single version, and always uninstall an existing version to install the requested one.

[jasnell]

It does not appear that there's anything further to do on this issue. The installer is operating as it was designed. We've talked about introducing a version manager in the past but haven't been able to make progress. Closing but we can reopen if folks feel the need to revisit.

[veganaize]

No problem. I've already uninstalled the official node package. Going forward I'll simply utilize the version included with graalvm.

Maybe the reason the project has been unable to make progress is because issues like this are closed instead requesting (public) comment? The internet was built on RFCs.

How about the implementation of a option in the installer, which alerts the user, allowing for installation in a separate folder, or an automatic uninstall (if they decline)? It could even be implemented as a command-line switch.

[ljharb]

Those capabilities already exist in the many existing node version managers.

[veganaize]

@ljharb Why doesn't this capability exist within the official node installer? I feel that it's burdensome to require a 3rd-party package to add one (relatively small and standard?) feature to node's installation.

[ljharb]

Because in practice, it is not small at all, or necessarily standard in other ecosystems. Even the installer allowing these things opens up a very wide range of possible edge cases and bugs, and would impose a quite large maintenance cost on node itself. I maintain nvm, one of the most popular node version managers, and i can assure you there is nothing remotely simple or small about this feature.

[veganaize]

@ljharb Complexity, like the elephant in the room, can be dissected and eaten one bite at a time.

Many software package installers allow the ability to "customize" the install. Allowing the program to install into a non-default folder is probably, far and wide, the single most prevalent customization feature available in Windows applications, today. What is it about node which prevents this otherwise small and standard feature to be implemented?

[ljharb]

If you consider it to be so small, then I'd invite you to write a pull request adding it.

[veganaize]

A pull request isn't the optimal place to have a discussion about potential features. Instead of closing issues, like this, I've found it much better to simply de-prioritize them and leave the ledger of discussion available (and therefore much less fragmented). When pull requests get rejected the entire thread gets thrown out. So only discussion around a particular implementation belongs with its respective pull request.

If it's not so small could you please (briefly) list the primary impediments in allowing a second installation, into a separate folder?

[Trott]

Maybe the reason the project has been unable to make progress is because issues like this are closed instead requesting (public) comment? The internet was built on RFCs.

As an aside, some kind of RFC process is under discussion (which is not the same as "will definitely happen"): nodejs/TSC#962

[jasnell]

Pull requests are always welcome, and are always given the priority over expectations that someone else should implement something you want.

When it comes to node.js version management, there are few here if any who understand the problem better than @ljharb, so if he says it's complicated it probably is.

list the primary impediments in allowing a second installation, into a separate folder?

1. Someone to implement it, and a pull request.

[Trott]

list the primary impediments in allowing a second installation, into a separate folder?

1. Someone to implement it, and a pull request.

In case that comes across as a bit flippant, I'd say:

1. A clear statement of how it would be implemented. (This "statement" could take the form of a pull request showing the implementation.)
2. A clear evaluation of support implications.
3. Identification of someone with the correct skills and interest to do the work.

For a more incremental approach, we'd need a map of the incremental steps. Or at least a plausible guess as to what the first incremental step is.

[veganaize]

I'd think the primary (incremental) step is the discussion we're currently having.

2. A clear evaluation of support implications.

Can we break this down into a few specifics? For instance, I know that (3rd-party?) module handling was mentioned in another thread.

[Trott]

I'd think the primary (incremental) step is the discussion we're currently having.

1. A clear evaluation of support implications.

Can we break this down into a few specifics? For instance, I know that (3rd-party?) module handling was mentioned in another thread.

I personally don't fully understand the support implications of having an installer that supports having multiple versions installed on Windows. So I rely upon the opinions of @nodejs/platform-windows and @nodejs/version-management folks on that stuff. However, that said, yeah, I can't imagine implementing this without a clear plan for how to deal with global modules.

With a per-user version manager like nvm, the location of the global modules directory is set based on the most recent nvm use. (That's an over-simplification--there's nvm install and you can probably play symlink games to mess things up and other things I'm not thinking of--but the point doesn't really change. In a per-user setup, you can usually reasonably rely on the user to pick things and even if stuff gets messed up, the stakes are usually lower when dealing with an individual user's setup.)

With a system install, there's tons of prior art to look at to see how "which global modules directory to use" is solved. (I'd guess most revolve around having one or more symlinks in places like /usr/local/lib/THING.) To pick one of a zillion possible examples, there's the very common scenario of having python2 and python3 both installed at the same time. While that's common, I also get the sense that it's been more than a bit of a support headache for the Python project and its users. But I don't know specifics. So maybe I'm wrong. More informed opinions welcome here.

Since this is still being actively discussed, I'm going to re-open this. We can always close it again later if a decision of wontfix or at least wontfix-anytime-soon is reached.

[Trott]

With a system install, there's tons of prior art to look at to see how "which global modules directory to use" is solved. (I'd guess most revolve around having one or more symlinks in places like `/usr/local/lib/THING.) To pick one of a zillion possible examples, there's the very common scenario of having python2 and python3 both installed at the same time. While that's common, I also get the sense that it's been more than a bit of a support headache for the Python project and its users. But I don't know specifics. So maybe I'm wrong. More informed opinions welcome here.

By the way, just in case it's not obvious, I'm not trying to say the problem is unsolvable. Just that there needs to be rough consensus on the suitability of whatever solution is chosen.

And I realize that what I wrote above (with /usr/local/lib and symlinks) is decidedly not Windows-centric, and this is a conversation about Windows. So, oops.

[veganaize]

Thanks @Trott! I just wanted a banana or two but you gave me a gorilla and the entire jungle!

Python keeps its modules (on Windows) under the same folder structure as the binary/program installation -- which is installed, by default, into a folder based on a Python<major><minor> version scheme. So Python 3.8 installs to C:\Program Files\Python38\. This allows the installation of every combination of major & minor version, out of the box, without need of any extra utility.

Could it make sense for Node, going forward, to install global modules (by default, on Windows) in a similar fashion --under the same (versioned?) folder as the program binaries? (It might already do this, as my NODE_PATH environment variable is unset, by default)

[ljharb]

Global modules can’t be safely shared across node versions, so that would be a strict requirement.

[veganaize]

Thanks @ljharb. Are there any other foreseeable (potential) impediments?

[targos]

Node and npm are mostly used as command-line programs. If there are multiple versions installed, which one is going to be executed when the user writes node --version or npm --version ? How would the user change that?

[veganaize]

Python's pip (a utility similar to npm) installs itself as pip, pip3, and pip3.8 when Python 3.8 is installed, for example. It uses a similar scheme, when installing the primary executables, python, python3, and python3.8 (on Linux).

Node could use a similar naming scheme and the Windows installer could continue to add the location of the executables to the PATH environment variable, as it currently does. The user could then adjust the ordering, of the PATH values, as desired / if necessary, using the system's GUI.

A more elaborate scheme could be devised but probably best to keep it simple, at least initially?

[jasnell]

This conversation is moving towards just reinventing the existing package managers that are out there. Would it not be more productive just to revisit the decision to bring in one of those existing things into core and iterating from there?

[Trott]

This conversation is moving towards just reinventing the existing package managers that are out there.

I'm not sure that's correct. My impression is that most of the version managers have per-user use as the primary use case. (n is an exception, but it does not support WIndows.) I'm not sure any of the Node.js version managers for Windows support system-wide installation of multiple versions. (@nodejs/version-management Please correct me if I'm wrong!)

[ljharb]

I believe that’s correct; however, that tends to be because it’s more useful to have per-user versions rather than systemwide ones (and removes permissions constraints).

[veganaize]

What if the Windows installer simply asks the user to confirm the uninstallation of the prior install? If they confirm then everything continues to uninstall/install as usual. If they deny then they are given the chance to change the install folder. As long as the install folder points to a prior install (as it currently does, by default) then they will either need to confirm, or deny and select a different folder.

No need for versioned executables or scripts. The installer could automatically update the PATH to point to the most recent install (as it currently does).

The silent uninstall is frustrating and unexpected behavior.

[veganaize]

I think the simplest compromise is to just download stand-alone binaries (or zips) and entirely bypass the installer.

Thanks!