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:
nodejs/TSC#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
#1 (comment),
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.

[brody4hire]

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 nodejs/TSC#96 (comment) 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.