Backstory on this repo

[williamkapke]

The Node.js TSC was ask to investigate moving the nvm project in to the Foundation. After much discussion/debate the TSC decided to create this repo where stakholders/experts from the node eco system can collaborate on what an official Node.js Version Manager would look like and offer to the community.

See original thread here: https://github.com/nodejs/TSC/issues/96

[delvedor]

An API to integrate this with the installer would be amazing! cc @mikeal @addaleax

[williamkapke]

Cool. We can use this issue tracker to list out "features" desired. That sounds like a good one!

[jasongin]

We might want to work together to build out a more complete version of the comparison table I built a couple months ago. That was based on a quick survey I did for my team, trying out all the popular tools I could find. (Some of the info there may be inaccurate or out of date.)

That survey was actually what inspired me to experiment with nvs, since I didn't find any single tool that worked cross-platform and had the features we wanted.

I'm working on converting the info into a format (not a giant table) that is more easily editable in Markdown.

[ljharb]

Perhaps we could set up a call so we could discuss overarching plans live, before writing too much up?

[jasongin]

I'm happy to join a call, if we can find a time with a significant number of participants available.

Separate from hearing about everyone's wish-list of features, I'd like to hear peoples' thoughts about the proposed goals of this working group:

a) a manager which supports all of Node's supported platforms and configurations; b) close collaboration between runtime and runtime manager development; and c) better useability for downstream developers,

we should bring together maintainers of these disparate projects and try to build at least one official Node environment manager with the best ideas and implementations from each project.

It does suggest "at least one official version manager". So it's possible the group could decide on an approach that narrows focus to two complementary tools (windows + non-windows), which should still be better than the 8+ we have now.

Personally I think a single cross-platform solution would benefit more from the combined development efforts. There would be some transition cost though, since as @ljharb pointed out on the other thread, an entirely new tool would need to consider migration paths from existing popular tools.

[MylesBorins]

I would be interested in being involved in this discussion

On Thu, Nov 3, 2016, 7:16 PM Jason Ginchereau notifications@github.com wrote:

I'm happy to join a call, if we can find a time with a significant number of participants available.

Separate from hearing about everyone's wish-list of features, I'd like to hear peoples' thoughts about the proposed goals https://github.com/nodejs/version-management/blob/master/initial_proposal.md of this working group:

a) a manager which supports all of Node's supported platforms and configurations; b) close collaboration between runtime and runtime manager development; and c) better useability for downstream developers,

we should bring together maintainers of these disparate projects and try to build at least one official Node environment manager with the best ideas and implementations from each project.

It does suggest "at least one official version manager". So it's possible the group could decide on an approach that narrows focus to two complementary tools (windows + non-windows), which should still be better than the 8+ we have now.

Personally I think a single cross-platform solution would benefit more from the combined development efforts. There would be some transition cost though, since as @ljharb https://github.com/ljharb pointed out on the other thread, an entirely new tool would need to consider migration paths from existing popular tools.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nodejs/version-management/issues/1#issuecomment-258302437, or mute the thread https://github.com/notifications/unsubscribe-auth/AAecV4ZNUqfp4Cw6L5IoJQ7PdN5B6s87ks5q6mtUgaJpZM4Ko_Rs .

[coreybutler]

I'd be open to a call sometime.

We need to start by defining what version management actually is before considering implementation details. For example, will the focus be on switching versions, using node, managing npm, workflow, all of these?

My personal vote in this matter is to keep it simple, focusing primarily on switching versions.

[ljharb]

Some existing use cases that are critical to preserve for any long-term solution:

1. works on common CI systems including jenkins, travis-ci, appveyor, etc
2. works on all environments node works on, including rpi. ideally, also works on archlinux, altho that might be tricky because it's got such a tiny subset of posix
3. Initial installation is not slow, and does not require large downloads.
4. works across bash, dash, sh, zsh, ksh, and ideally fish too - this is easy doable if it's not a sourced shell function

[ljharb]

@coreybutler i think definitely just installing/removing/listing/switching node versions is a good MVP.

[brodybits]

I hope I can join the call. I am in Amsterdam (GMT+1). I like the "installing/removing/listing/switching node versions", "works on common CI systems", and "works across bash, dash, ..." ideas.

As I said in https://github.com/nodejs/TSC/issues/96#issuecomment-258273099 I would highly favor the following characteristics:

• supports major platforms (Windows and *nix)
• mostly written in JavaScript

@jasongin identified jasongin / nvs which would support both of these characteristics.

I also like the Electron-based nodejs / installer idea and wonder if we could make it work with a mostly-JS tools like nvs?

[Fishrock123]

I'd definitely like to join and help move these discussions along if possible

[jasongin]

I also like the Electron-based nodejs / installer idea and wonder if we could make it work with a mostly-JS tools like nvs?

Sure, nvs could be referenced from Electron like any node library package. (It probably just needs a bit of work to make the public API surface more well-defined.)

So yes, nvs might make a good foundation for a cross-platform version manager tool, but I'll let the rest of the group make that evaluation. (Obviously I'm biased.) If the only result is that a few ideas get borrowed from nvs and incorporated in some other consolidated solution, then I'll still consider it a successful experiment.

[ljharb]

I created a whenisgood for saturday up until the 17th - please sign up with your github handle and available times for a call. There's a lot of us over a lot of timezones, so please highlight any times that are doable, as opposed to just times that are convenient/easy.

http://whenisgood.net/nodevmwg

I'll plan to close it down / pick a time by late Friday night PST - which gives about 31 hours for people to sign up.

[ljharb]

So far there's only one time that everyone can make it - Tuesday, November 15th, at 9AM PST (I can stretch and make 7 or 8 AM the same day if needed). If anyone else is interested in attending, or if anyone who's responded has had some times open up, please add/update your response on the whenisgood. I'll close it down and finalize a time in about 7-8 hours.

[ljharb]

k, looks like it's finalized - Tuesday, November 15th, at 9AM PST. I'll post a conference link here a couple days beforehand.

[ljharb]

I've added the email addresses I could find to the conference link. Talk to you all in 16 hours!

[jasongin]

Following are my notes from the conference call. I hope I captured the key discussion points accurately; let me know if I need to edit anything. (The meeting was also recorded.)

Attendees

• Jordan Harband @ljharb
• William Kapke @williamkapke
• Myles Borins @TheAlphaNerd
• Jeremiah Senkpiel @Fishrock123
• Corey Butler @coreybutler
• Chris Brody @brodybits
• Marcel Klehr @marcelklehr
• George Adams @GeorgeAdams95
• Jason Ginchereau @jasongin

Notes

Jordan started by talking about adoption of nvm into Node foundation as being separate from the longer-term WG goal.

• Myles, while supportive, was trying to better understand Jordan's reasons. Jordan's answers included: governance (so the project's survival doesn't rely on a single maintainer), licensing support, testing infrastructure.
• Jeremiah relayed the TSC's conerns about a project joining the foundation only to stagnate/die. Jordan suggested it would still be better for a project (particularly one having a lot of users/infrastructure depending on it) to stagnate while under the foundation rather than not under it, and also suggested the foundation membership didn't have to be permanent: a project could be deprecated or removed after it was replaced by something newer.
• Others were still concerned about the adoption leading to the perception of nvm being promoted as the "standard", even if that was explicitly not the intention.

Corey and Myles suggested the WG should develop "standards" for all version management tools so they work in a consistent way.

• (Think of the Promises/A+ spec that many JS promise libraries converged on.)
• Marcel asked whether there's any benefit to having multiple tools if they are all implementing the same standard.
• Jason pointed out standards would have to be limited in scope to avoid dictating specific switching mechanisms and thus excluding many tools.
• Jordan thought that the standards could leave room for different tools to be better adapted to different platforms or scenarios.
• There was some concern that standards (or version-switching in general) could not be implemented consistently across platforms, for example symlinks; Jason pointed out that is largely disproven by nvs.

Jeremiah is interested in a GUI installer using a version manager or potentially selecting from multiple version managers.

• It could replace the existing Windows (MSI) and Mac installers which are difficult to maintain.

George and Chris promoted nvs as a potential solution/inspiration for a converged tool.

• Jordan agreed nvs is closest being the best long-term design approach.
• Jordan was concerned nvs's approach isn't suitable for some corner cases (and maybe no single tool could cover all of them).

[searls]

For what it's worth, and realizing I'm swooping into the discussion having missed this conference call (forgive me for this), I'd like to propose consideration for nodenv. There exists a cadre of other "xenv" projects originally derived from rbenv, but who keep their core codebases in sync with one another. As a user, I've used several others, and I find nodenv to be the most reliable I've seen.

There are a few benefits I'd like to highlight here that set nodenv apart from other tools.

For polyglots that work in multiple languages, the emergence of "xenv" shell-script tools that share the same commands, conventions, and codebase has really been fantastic to work with. There are a number of ports that all behave predictably once you've used one "xenv" tool like goenv and pyenv. Additionally, each individual project has been surprisingly good about sending improvements upstream, which benefits users of each language.

One related reason for considering nodenv is that these environment managers are a success story of separation of concerns. The problem they're solving is to provide a stable and secure interface for developers to manage multiple installations of a given language. It may be counter-intuitive, but years of practice have shown that these "xenv" tools need to know remarkably little about the language themselves to be full-featured. Typically, each individual xenv tool only needs to concern themselves with a language's particular release strategies and any idiosyncratic requirements of the language's dependency system.

In parting, this is something the Ruby community has been dealing with for at least 6 or 7 years and I'm sure would be glad to help you all with, beyond just myself. Like nvm, rvm was the first to solve developers' immediate problem and gained massive user share, but had some (hotly debated) drawbacks, too. It also never developed the breadth of contributor-ship needed to remain secure and compatible across a wide range of systems. rbenv, meanwhile, solved a number of architectural problems, and its design lent itself to supporting other languages as well, which has broadened the contributor base and resulted in a more robust, sustainable set of projects.

[jasongin]

@searls nodenv and other "xenv" tools are written in bash script and therefore don't support Windows. But the node community, including the members active in this group, have consistently agreed that if there is going to be convergence on a single solution then it should be cross-platform.

[jasonkarns]

@jasongin one minor nitpick I have with the comparison table is the claim that:

nodenv cannot use 32-bit node on 64bit system

It's partially true, in that node-build will match the precompiled binary precisely. Though node-build will also do compile from source if requested. Regardless, nodenv itself does not care about the platform or the installed nodes. Dropping a node installation into its versions/ directory will make it usable by nodenv regardless of platform.

[jasongin]

OK, I'm not surprised there are some minor inaccuracies in that table, since it was a quick survey and I didn't have time to get super familiar with every tool. But still I'd say it is not architecture-aware, meaning you wouldn't be able to easily install and switch between x86 and x64 builds of the same node version.

[jasonkarns]

you wouldn't be able to install with node-build, no. but once installed, nodenv could switch between them just fine. It should be as simple as dropping 7.0.0-x86 and 7.0.0-x64 (names of your choosing) into nodenv's versions/ directory.

[jasonkarns]

I'm curious if the windows support question has been answered for us by Windows 10 now that bash itself runs on windows.

[jasongin]

Bash on Windows is far from mainstream even among Node.js users, so I don't think that qualifies as Windows support. Note a version manager tool that runs inside Bash on Windows would be installing and managing Node binaries for Linux (not native Windows binaries), which is probably not what most people want when they're working with Node on Windows.

[jasonkarns]

a version manager tool that runs inside Bash on Windows would be installing and managing Node binaries for Linux (not native Windows binaries)

Not sure how you can claim this. I would suspect that uname, etc would provide some windows-specific info that would make it trivial to install the correct binary.

And I agree that it's not mainstream. But if bash-based toolchains are soon to be supported natively on windows (which is a big IF), then it reduces the need for a cross-platform tool.

[jasongin]

Sorry don't want to be too negative. I should have started by saying: Welcome to the discussion! We are glad to have representatives from another popular node version management tool involved.

uname, etc would provide some windows-specific info that would make it trivial to install the correct binary

Actually uname just reports Linux and doesn't mention anything about Windows:

jasongin@JASONGIN:/mnt/d$ uname -a
Linux JASONGIN 3.4.0+ #1 PREEMPT Thu Aug 1 17:06:05 CST 2013 x86_64 x86_64 x86_64 GNU/Linux

Still, there are some ways (hacks?) for a bash tool to detect if it is running on Windows, e.g. by checking for a /mnt/c/Windows directory. But there would be significant limitations then: a process in the Linux subsystem can't access the Windows registry, so it can't modify the user profile PATH. And the Linux subsystem is entirely per-user so it can't manage versions at the system level, or do anything that requires admin privilege on Windows, meaning no linking into Program Files or modifying the system profile PATH. (Root in the Linux subsystem does not have admin privilege in Windows.)

[jasonkarns]

Those extra limitation are exactly what I was looking for, thanks! I figured there would be some way of detecting that it was running on windows. And, to be honest, all of the uname/lsb_release detection bits in most node installers are already huge hacks (akin to ua-sniffing, IMO). Good to know, though, that the bash-on-windows scenario isn't a near-term viable option for bash-based switchers. (I've been curious for awhile, but yet to have experimented.)

[jasongin]

FWIW, I've been using Ubuntu Bash on Windows to validate cross-platform functionality as I develop NVS mostly in a Windows environment, and it's been great for that since I can run from literally the same development directory without having to sync any changes across. I still do some testing on actual Mac and Linux systems (or VMs); that has caught some Mac vs Linux differences, but so far no Bash on Linux vs Bash on Windows issues.

[ljharb]

(fwiw, nvm already works on BashOnWindows as well; I agree that that doesn't count as windows support, since node itself doesn't require it)

[gdams]

@jasongin my GitHub id is @GeorgeAdams95 btw

[coreybutler]

Just some points on bash support: There are still a lot of users on older Windows systems, despite the fact Windows 7 support expired some time ago (except for extended enterprise support). Older OS support is even more prevalent for server editions of Windows, especially in enterprise environments where policy/licensing makes it harder to refresh/upgrade the OS. For at least the next few years, it is not safe to assume bash (or even powershell), will be available. It's also not safe to assume bash is available on all Linux systems. Alpine Linux, which is slated to be the new Docker base image, does not ship with bash by default.

[gdams]

@coreybutler I don't personally feel that powershell is going anywhere any time soon. Microsoft is still investing a lot of money into making it the leading windows command utility. I also agree with the comments though that supporting windows 10 because it 'supports' bash cannot exactly be classed as windows support. To me this solution needs to start as a bash tool and a batch/powershell tool (ideally powershell as it would seem a much better choice to me). How we then develop the version manager from that point obviously depends on a lot of unknowns right now. Will windows officially support bash any time soon or will it stay beta for a long time? @ljharb any thoughts?

[ljharb]

I think that whatever long term solution we settle on needs to have cmd.exe support as a first-class citizen right out of the gate - BashOnWindows is a great temporary workaround for tools for now, but I agree it's definitely not enough to claim "Windows support".

[gdams]

I would definitely be interested in maintaining support for aix and s390 as I feel that these are really important operating systems to be supporting. I would also like to try and add zOS support to whatever final solution we come to.

[williamkapke]

This thread has completed my initial intention of providing some context for visitors while things were ramping up.

😄