replace desktop installer with version-management installer

[MylesBorins]

Currently we are maintaining both a .pkg and a .msi installer for OSX and Windows. Not only are these baroque, but they are error prone.

I'd like to suggest that we replace both of these with the electron based installer and include version management as a feature in the installer.

It is possible to do over the wire autoupdate on electron apps, this would likely solve quite a number of our problems.

[coreybutler]

I agree it would be nice to replace all installers with a version manager installer. I have hesitations about Electron/NWJS though. For one, it seems like a "recreate the wheel" situation. FWIW, BitRock offers open source projects a free enterprise license for creating cross-platform installers. Personally, I've found it to be pretty straightforward.

Electron ships a whopping 45MB footprint. This would be the biggest version manager of any language. It also adds a new component to the overall management... someone's gotta maintain the UI.

Electron isn't the only evergreen player. Go also has evergreen capabilities, thanks to go-update. It can do binary diff updates. This is how ngrok works (same author). I know, I know... not JS. It's really not that hard.

[ljharb]

It's not about being "hard", it's that things should be accessible to node dot js users, who use JS. Using Go will drastically limit the number of possible contributors, and I don't think any language or filesize benefits are worth that.

[MylesBorins]

so something that I am hinting at here and in #3

If we standardize the folder layout and the way in which the path is shimmed for different environments then people can use whatever run time they want. We can have an official installer built in electron, you could make a tool bar item that can switch versions, you could then use nvm to switch if you prefer.

One other thing to consider with file size... if we can do OTA updates then file size is a bit of a null point

[delvedor]

@TheAlphaNerd we already have a first implementation of the electron based installer :) Every suggestion is welcome!

https://github.com/nodejs/installer

[coreybutler]

@ljharb - We also don't need thousands of contributors. I've had 2 people say Go was a blocker, but that hasn't prevented the inclusion of some fantastic contributions. Don't get me wrong... I would prefer a JS based solution, I just don't think Go is a bad alternative and it has a number of advantages in dealing with cross-platform system issues.

@TheAlphaNerd - Remember that Squirrel, which is responsible for Electron OTA, expects a complete app, not a diff. Every update will ship the full app, so file size is still going to be comparatively large.

I agree 100% on standardizing a folder layout and shimming.

For shimming, my vote is for symlinks.

On windows, making changes to the PATH require elevated admin privileges (not good enough to just be an admin). The same is true for making any change to C:\Program Files or any subdirectory within. I tried to avoid that by only touching the PATH during the installation process (i.e. set it and forget it). By specifying a path to a known symlink residing in a location that doesn't require elevated admin privileges, changing it is trivial. One of the mistakes I made was giving users a choice of where they wanted to put the symlink. Most users picked C:\Program Files\nodejs anyway, out of habit, despite warnings. This causes 2 UAC prompts whenever the symlink changes... one to remove the old symlink and one to create the new one. Avoiding C:\Program Files would avoid these prompts.

This approach automatically updates all versions, including open terminals. It truly treats the environment as though the version manager weren't there at all, just as if you were to install a new version node, that would be the active version.

As for folder structure, I used a one-folder-per-install approach. I did not split it up by architecture (32 vs 64-bit). In retrospect, that was probably a mistake. It probably should be split by arch as well. The argument several users made was some native modules built using 64-bit architecture failed to work in a 32-bit environment. The downside is this can leave a pretty large overall footprint.

[jasongin]

On windows, making changes to the PATH require elevated admin privileges

It's possible to update PATH for both the current shell and the current user profile without requiring admin privileges. Only system PATH changes require elevation.

A symlink is nice for some scenarios, but limiting for others, such as when you want to select a node version that is per-shell or per-directory. That's why NVS makes complementary use of both PATH changes and symlinks.

[coreybutler]

@jasongin - you're correct, I should have been more specific about the system PATH. I've found most users are setting this up system-wide... but that's just my experience (I'm not saying it's right, but it's what people have been doing).

I opted for globally changing the version of node instead of per-terminal because that was the closest representation of what a user would have to do with no version manager installed. From my perspective, per-shell versions are a function of workflow/opinion... not of simply switching what's installed. Per-version versus global use has produced some heated discussions. Sentiment seems to be split 50/50.

This is why I suggested defining what we mean by version management. If we're just proposing version switching, it should operate the same way it would if the user had to do this by hand (i.e. global). If we're proposing a workflow, then we should propose a standard for per-shell use.

[jasongin]

Per-[shell] versus global use has produced some heated discussions. Sentiment seems to be split 50/50.

Yes! And actually it's split in more than 2 ways. As @marcelklehr mentioned in the other issue, there are really four scopes for version management:

1. system-wide
2. per-user
3. per-terminal
4. per-directory

Managing versions at different scopes is appropriate for different scenarios. That's part of why there are so many different version-management tools available today. I think any converged solution that aims to meet everyone's needs must support at least the first three scopes, and ideally all four.

[wilmoore]

In order for this project to be an overall success, the above "scopes" as pointed out by @jasongin must be addressed and treated with equal importance.

[MylesBorins]

This doesn't seem to be going anywhere. Please feel free to open a new issue if anyone wants to explore this again.