The Windows installer (a.k.a the 🐘 in the room)

[refack]

So for some unknown historical reason node core has a Windows installer (probably to appease the MS gods)...
After a recent conversation with @ljharb, IMHO the installer should be in this WG's focus, since it's essentially a "management-challenged" version manager....
We are fielding issues as:

• Allow multiple installs of Node on Windows with msi
• Stop the installer deleting my symlink for AppData\Roaming\npm
• Windows installer: Per user install (feature request)
• and the list goes on...

Which bring up the same issues that are discussed here, like:

• where do we put the global node_modules?
• Should we install npm or not, and where?
• Does core want to officially support side-by-side multi-version, and if so how to switch versions (i.e. version manager yes or no)?
• How to detect which version are installed?

Not to diminish from this WG's efforts in the least, and not intending to step on anyone's toes!!!
It's just that our questions are less "academic" since they are motivated by issues opened by users, since the Windows installer is unfortunately an existing core feature 🤦‍♂️ So we need to answer them sooner rather than later...
BTW: Personally my prefered answer would have been "The Windows installer is deprecated, use the zipped package or a userland version manager" but it got push-back nodejs/node#4603 (comment)

/cc @tniessen @nodejs/platform-windows

[MylesBorins]

Fwiw the osx installer is in equal disarray Have you seen nodejs/installer?

…

On Jul 14, 2017 12:18 PM, "Refael Ackermann" ***@***.***> wrote: So for some unknown historical reason node core has a Windows installer (probably to appease the MS gods)... After a recent conversation with @ljharb <https://github.com/ljharb>, IMHO the installer should be in this WG's focus, since it's essentially a "management-challenged" version manager.... We are fielding issues as: - Allow multiple installs of Node on Windows with msi <nodejs/node#4603> - Stop the installer deleting my symlink for AppData\Roaming\npm <nodejs/node#7882> - Windows installer: Per user install (feature request) <nodejs/node#13830> and the list goes on... <https://github.com/nodejs/node/issues?utf8=%E2%9C%93&q=is%3Aissue%20label%3Awindows%20label%3Ainstall> Which bring up the same issues that are discussed here, like: - where do we put the global node_modules? - Should we install npm or not, and where? - Does core want to officially support side-by-side multi-version, and if so how to switch versions (i.e. version manager yes or no)? - How to detect which version are installed? Not to diminish from this WG's efforts in the least, and not intending to step on anyone's toes!!! It's just that our questions are less "academic" since they are motivated by issues opened by users, since the Windows installer is unfortunately an existing core feature 🤦‍♂️ So we need to answer them sooner rather than later... BTW: Personally my prefered answer would have been "The Windows installer is deprecated, use the zipped package or a userland version manager" but it got push-back nodejs/node#4603 (comment) <nodejs/node#4603 (comment)> /cc @tniessen <https://github.com/tniessen> @nodejs/platform-windows <https://github.com/orgs/nodejs/teams/platform-windows> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#16>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV0pyiI6pYJZy0SazNTJ4A22Etuujks5sN06YgaJpZM4OYIi6> .

[refack]

Fwiw the osx installer is in equal disarray

Have you seen nodejs/installer?

Ohh yeah sorry I meant to mention the osx installer.

[refack]

Have you seen nodejs/installer?

I keep forgetting it... But again it has the benefit of cooking behind the scenes while the Windows and osx installers are out there causing headache...
/cc @nodejs/electron-installer

[MylesBorins]

So fwiw this is pretty close to the conclusion we reached at at the last collaborators Summit We need to completely overhaul our installers, and likely move towards a version manager. Likely move away from /user/local, and try and standardize where stuff loves to make it easier to move between tools! The latest work has been happening in the installer repo, but we should perhaps make a more directed effort. This should like be a joint effort between build and release

…

On Jul 14, 2017 12:21 PM, "Refael Ackermann" ***@***.***> wrote: Fwiw the osx installer is in equal disarray Have you seen nodejs/installer? Ohh yeah sorry I meant to mention the osx installer. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#16 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV6SqOkNVtjphjrfpIPWL5_ytZfUmks5sN08jgaJpZM4OYIi6> .

[benjamingr]

Hey, I think our install should have the following properties:

• Installable from package managers on the 3 biggest platforms (choco on windows, brew on linux, apt/pacman/whatever on linuxes).
• Installable as an installer on Windows and Mac where this sort of installation is popular. For what it's worth the windows/mac installers do a pretty good job today - and for the 95% of users they work pretty well.
• A standalone installer would be nice (that doesn't touch anything global) for all three platforms - personally I just grab the source and build when I need this but I don't think many users do that.

I think it's worth saying that overall our installers - while in disarray - work pretty well. Especially compared to other platforms and stacks (installing Node is much simpler than installing Python+Flask for example which is one of the simpler stacks).

I'm -1 on any option that doesn't include NPM as well (since it is a vital tool for developing Node.js with our small core). I'm fine with revisiting letting the user pick a package manager - but honestly NPM works well enough for most users with most use cases IMO anyway.

[MylesBorins]

@refack a replacement has to happen in the background... I have yet to hear of a sustainable way of building on top of what we currently have. I totally support driving more aggressively towards this happening, we just need people to invest time

…

On Jul 14, 2017 12:32 PM, "Benjamin Gruenbaum" ***@***.***> wrote: Hey, I think our install should have the following properties: - Installable from package managers on the 3 biggest platforms (choco on windows, brew on linux, apt/pacman/whatever on linuxes). - Installable as an installer on Windows and Mac where this sort of installation is popular. For what it's worth the windows/mac installers do a pretty good job today - and for the 95% of users they work pretty well. - A standalone installer would be nice (that doesn't touch anything global) for all three platforms - personally I just grab the source and build when I need this but I don't think many users do that. I think it's worth saying that overall our installers - while in disarray - work pretty well. Especially compared to other platforms and stacks (installing Node is much simpler than installing Python+Flask for example which is one of the simpler stacks). I'm -1 on any option that doesn't include NPM as well (since it is a vital tool for developing Node.js with our small core). I'm fine with revisiting letting the user pick a package manager - but honestly NPM works well enough for most users with most use cases IMO anyway. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#16 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecVw8tyHDsK8K9r6XODAvBpKCaIBLZks5sN1G8gaJpZM4OYIi6> .

[refack]

@refack a replacement has to happen in the background... I have yet to hear

Agreed, my question is what do we do meanwhile? Improve the existing installers? Recommend userland VerMan (nvm / nvs) ? Say: wait for "The Installer"?

BTW: As I see it any work we do meanwhile on the windows (MSI) installer, could and should be harnessed the "The Installer" and any VerMan

[benjamingr]

@refack I'll just say this clearly one more time - I don't think the situation with the windows installer at the moment is all that bad - and neither is the situation with the macOS installer. I'd like any new installer you work on to be at least as easy to use as the existing installers since environment set up is a huge problem in my experience for new users.

(Of course - I agree that we can do a better job with both the installers and I think you're doing an amazing job being on top of the windows platform, the installer, and issues people have - which historically Node didn't do as good of a job with as other platforms.)

[refack]

@refack I'll just say this clearly one more time - I don't think the situation with the windows installer at the moment is all that bad - and neither is the situation with the macOS installer. I'd like any new installer you work on to be at least as easy to use as the existing installers since environment set up is a huge problem in my experience for new users.

Our (@tniessen and I's) efforts are not to replace, but only to improve the existing Installer.

P.S. MSI installers packages (which the existing Installer is) are officially supported by Microsoft, use OS APIs, and are dependent on by our users nodejs/node#4603 (comment). So AFAICT even "The Installer" will need to live side-by-side with.

[MylesBorins]

There are geniune problems with the widows installer regarding how it handles the non directory and inability to remove files. We are also limited in expanding functionality. On Jul 14, 2017 12:52 PM, "Refael Ackermann" <notifications@github.com> wrote: @refack <https://github.com/refack> I'll just say this clearly one more time - I don't think the situation with the windows installer at the moment is all that bad - and neither is the situation with the macOS installer. I'd like any new installer you work on to be at least as easy to use as the existing installers since environment set up is a huge problem in my experience for new users. Our (@tniessen <https://github.com/tniessen> and I's) efforts are not to replace, but only to improve the existing Installer — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#16 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecVwrvW3T6yUZQn2HAg0kO-J2SVJANks5sN1Z-gaJpZM4OYIi6> .

[refack]

There are geniune problems with the widows installer regarding how it
handles the non directory and inability to remove files. We are also
limited in expanding functionality.

@refack I'll just say this clearly one more time - I don't think the situation with the windows installer at the moment is all that bad - and neither is the situation with the macOS installer. I'd like any new installer you work on to be at least as easy to use as the existing installers since environment set up is a huge problem in my experience for new users.

Just to add, Installers are hammers not surgical scalpels. They assume stuff about your system, and they read/write/delete system files in an irreversible way. Any bug can lead to a catastrophe for the user.

(biased and not 100% correct list, but totally real)

• Node install destroyed PATH
• Installer puts down npm 4.5.0, not 5
• nodejs LTS v6.10.2 Windows installs give npm version 1.4.2 instead of 3.10.10
• Windows installer can corrupt its npm installation
• Win64 .msi install breaks Windows Explorer.

[ljharb]

I think I can say, without a doubt, that whatever version management solution we end up eventually coming up with and shipping as part of node will have the following characteristics:

1. works on every officially supported platform
2. can install multiple versions of node at a time, and switch between them on a systemwide/per-shell/per-invocation basis
3. is sufficient to replace any other form of installer (even if other means remain, like untarring and make/configuring)
4. can elegantly handle permissions issues, including providing a mechanism to fully function without any special privileges

I'm sure there are more things that can go on this list, but that's just some things off the top of my head.

Other thoughts:

1. the global node_modules must not be shared across node versions; every version of node needs a separate reinstall of packages, for compilation reasons if nothing else (there's also packages that dynamically load different JS based on which node version it's running in, and this could easily happen at postinstall time too).
2. npm comes with node always. It should never be installed separately, and it should always start out initially as whatever version ships with that stock node version. If people want an option to npm install -g npm at the same time, that's great, but that should be the mechanism by which it's upgraded.
3. side-by-side different versions is version management, and should not be supported until the solution mentioned above is ready. Side-by-side of the same version is a weird use case, so I'm not sure it should be supported at all, but if so, it'd also be version management.
4. node -v detects which version is installed.

[jasongin]

I think there are two important questions that need to be answered before we can move forward to proposing solutions:

1. Is it a requirement that Node installers use the OS-specific installation technologies? For Windows, many people, especially system administrators, expect software to be delivered via MSI packages. MSI installers have consistent command-line options, can be logged, inventoried, deployed via group policy, etc. I'm less familiar with installers on the Mac, but I'd imagine there are similar considerations. Are there benefits of moving away from the OS installation technologies that would outweigh the drawbacks?

2. Should Node installers participate in / be aware of version management? Currently version manager tools do not actually use the platform specific installer packages; they always download and extract the .tar.gz/.zip packages directly (as far as I know). And then the version-manager needs special-case logic to deal with any Node version that might have been installed separately.