Investigate moving nvm into the foundation

[ljharb]

• What would be involved in moving https://github.com/creationix/nvm to the Node foundation?
• Is this something the foundation is interested in?
• Other than transferring the repo into the github org, what licensing, governance, CoC, TSC, etc changes would need to be explored?
• How would this affect the direction of nvm itself?
• are there any conflicts of interest, or messaging concerns, created by this project living in the foundation?

[MylesBorins]

Super +1 on this happening. I don't necessarily have answer to all of those questions but I believe that is the point of the incubation process.

[williamkapke]

I do not think the TSC is currently accepting applications for Mentorship/Incubation/TLPs at this time. See: #73 (comment) . But, I perhaps this is just to have a "what if" conversation without the formalities...

From what I understand, TLPs are something that has been determined to be "vital to the node ecosystem" and is at risk of becoming unstable without assistance. Express being a current example.

Maybe you can provide more context as to why the Node.js Foundation's resources & assistance are desired/needed?

are there any conflicts of interest, or messaging concerns, created by this project living in the foundation?

This would make it a "blessed" project which has been discussed & debated by the TSC before. I can't speak for all of the points of views on that- so someone else will need to elaborate on it.

[jasnell]

@williamkapke ... I'm not sure this is something that we would need to spin up too much process around... that is, I don't think we'd have to treat it as a top level project any more than we treat citgm as a top level project (for instance) or the docker-node stuff. It can simply be a tool that lives within the nodejs org.

the key question for me would be: are there other competing similar packages that would be disadvantaged by moving this into the org?

I think I'm +1 on this.

[Fishrock123]

I think we should ship a version manager. (But I'm pretty sure there are others who disagree.)

Or, at the very least, bundle one like we bundle npm.

I'm not sure that correlates to bringing an existing one into the foundation, and probably not at the current time.

[williamkapke]

ah. Rather than being a TLP, this would be something under the Core's domain... maybe...?

are there other competing similar packages that would be disadvantaged

I'll throw https://www.npmjs.com/package/n out there to be noted.

[jasnell]

If we bundled one I'd definitely want to bring it into the foundation first.
I've always found it mildly irritating that we don't already ship a version manager.

[MylesBorins]

The one advantage to nvm compared to most other node version managers is that it is implemented in POSIX. This has the disadvantage of not necessarily supporting windows, but it does make it very portable, and can run without having to have node installed first

With the windows ubuntu subsystem perhaps there is a way to get it working, as long as nvm is the only running in that subsystem to install node on the main system (as bash on windows is still not able to support npm).

[mikeal]

Even if it weren't bundled it would benefit from being more integrated into core development.

Does anyone know market share between nvm, n, and others node version managers?

[MylesBorins]

Doing some scientific research... please retweet

https://twitter.com/thealphanerd/status/725909274753261568

[jasnell]

according to numbers on npm...

nvm:

• 395 downloads in the last day
• 1,827 downloads in the last week
• 7,933 downloads in the last month

n:

• 7,379 downloads in the last day
• 48,944 downloads in the last week
• 197,293 downloads in the last month

[mikeal]

nvm isn't really installed by npm tho, so they won't have great data there.

[MylesBorins]

nvm is not generally downloaded by npm... @ljharb do you have the clone numbers from github?

[jasnell]

Yes, I know ;-) ... I'm adding to the market research, not providing all of it ;-)

[williamkapke]

https://www.npmjs.com/package/nvm doesn't have a valid link to the github repo which might turn people away.

[ljharb]

The one on npm is broken and from a legacy package - so none of its numbers are useful.

However, nvm is used on travis-ci for every single nodejs project, and I'm going to go out on a limb and say that it has more than 197K test runs in a month.

[thefourtheye]

@ljharb As nvm is already a popular project, with active contributors and maintainers, what do you think it would get out of coming under the Node.js umbrella?

P.S: I am not against this movement, but I am just trying to understand the motivation better. Please ignore if it is not appropriate to discuss it here.

[ljharb]

I think that the node core team and I already cooperate sufficiently to ensure that things continue to go smoothly between node and nvm, and I think the project has enough notoriety on its own that it doesn't need any bump from being "blessed" in any form.

However, I'm particularly hoping to benefit from a proper governance process, and to ensure that the project survives if I move on (not that I plan to for the time being) and if the current repo owner isn't available or willing to resume maintaining it.

While nvm is currently not "at risk" in any capacity I'm aware of, it seems to me to be better to plan in advance, rather than waiting until such a problem appears (like Express, for example).

As for other projects, the other two node version managers I'm aware of that have significant usage are indeed n, followed by nave - all three of these projects are for different (albeit slightly overlapping) use cases, so I don't see them as competitors, more as alternatives. If nvm were to join the foundation, and one of the alternatives wished to as well, I wouldn't personally see that as a conflict.

[orangemocha]

I am a bit concerned about the 'blessing' effect. To be honest, I am a bit concerned about nvm's lack of Window support.

And FWIW, if we were to bless a version manager, I kind of like nodist's approach better as it uses shim and supports version switching per directory, per app, in addition to per machine.

[ljharb]

@orangemocha fwiw, nvm now works on the latest BashOnWindows (although node itself doesn't yet).

nvm supports version switching per directory as well, via .nvmrc and a manual nvm use, we've just made the choice not to obtrusively modify cd for users - but there's examples in our readme of how to easily do this.

[orangemocha]

My comment was a bit of raw brain dump, sorry. To better summarize my feedback:

1. If we are not trying to bless a version manager, let's think about what other motivations would be served by nvm joining the Foundation.
2. If we think that Node needs to ship with a version manager, and hence we want to bless one, let's make sure that it has the 'right' architecture for Node, or the roadmap to make it so.

[Fishrock123]

cc @nodejs/ctc @nodejs/tsc

[mscdex]

Yes, platform compatibility is one issue that comes to mind (mostly Windows doesn't seem to be a first class citizen in the version managers I've seen).

[nebrius]

I'm +1 on @orangemocha's suggestions re: Windows. I'm wary of officially blessing a version manager if it doesn't support/has weak support for Windows.

That said, bringing a version manager into the foundation could be a good opportunity to get first class support for Windows into such a version manager.

[evanlucas]

Don't forget fish shell either...unfortunately it does not work with fish (I know there is a port of it, btw)

[ljharb]

I'm not opposed to adding Windows or non-POSIX support to nvm, especially as part of the node foundation - primarily it's been an issue of contributor time, as well as the ease of automated testing.

[evanlucas]

@ljharb that's good to know. That would be awesome (for me, at least) Thanks!

[Fishrock123]

Don't forget fish shell either...unfortunately it does not work with fish (I know there is a port of it, btw)

Most of us who use fish just call into bash for these things? Idk

[ljharb]

A fish implementation for nvm would likely just be a wrapper around nvm itself that calls into it via bash, which is how most of the existing fish wrappers are implemented.

[coreybutler]

I want to toss https://github.com/coreybutler/nvm-windows into the mix. It's grown in popularity... reasonably quickly (~150 Github stars to 1300+ in the last few months). The README lays out the approach to version management, which is a bit different from some of the other version managers (including the original nvm). The key bullet points are:

1. The core code base is 100% Go. No dependencies*. Designed for cross-platform uniformity.
2. Uses PATH, pointing to a changeable symlink for version switching.

*There are some helper scripts specifically for Windows, most of which I believe Go has now natively addressed (i.e. these should be able to go away).

By not having any dependencies on node or npm, it remains flexible & independent of those code bases. The obvious downside is contributors need to know Go.

Roadmap

While NVM4W currently only supports Windows, I am actively developing Mac & *nix versions from the same code base. Go has been excellent for this. There will be a name change when I reach the next release point.

Frankly, the code is the easy part. The time suck has been preparing installers & proper builds across Appveyor, Travis, homebrew/chocoloatey/yum/etc. I've struck a deal with BitRock to simplify this to a degree, but the project would benefit from having a maintainer for each type of installer (specifically non-visual installers like chocolatey).

I also really like the auto-update capabilities Go can potentially provide for a CLI tool, so I've been exploring that.

Usage

NVM4W ships with "installer" and "no-setup" versions (for those who want to make their own silent installer). According to my Github stats this morning, v1.1.0 has 37,908 installer downloads & 9,954 "no-setup" downloads. This only includes usage since v4.x.x was released. However; I suspect these numbers to not accurately represent real usage. I believe they're low, because I'm constantly getting questions about enterprise deployments through Active Directory, mirroring downloads, or other on-premise distribution means. That can't really be tracked. It also amazes me how many devs are stuck on older versions of Windows... point being the recent inclusion of bash in Windows will take some time before reaching enterprise folks.

Foundation Blessing

If the foundation doesn't adopt/bless a specific tool, it should still set standards. For example, the original Joyent repo didn't have a clean way of obtaining version data, which lead to the ugliness that is nodedistro. That's an iron.io script that scrapes data from the releases page. Now that releases are published in a nice JSON feed, this is no longer a problem (switching is a top priority on my roadmap). The point is foundation-blessed standards and a means of understanding them will drive development.

One "sort of" outstanding issue is naming. NVM4W still uses "stable" and "unstable" since I haven't yet had time to incorporate LTS & Current. I don't think there's much that can be done about that now, but it's indicative of how changing a standard will impact workflow.

The blessing of the foundation will impact user trust. We all know decisions are often based on the "official" choice of the authoritative body, especially within enterprise.

As @ljharb mentioned, governance would benefit a number of projects (NVM4W included). I believe there are multiple "right" approaches to version management. Has anyone considered some sort of standards compliance "certification" process?

Bundling

While the concept of version management could live within the foundation, it should not be bundled with node itself. In other words, don't ship it with a download. It would need to be a separate tool that traverses multiple versions... bundling it with each version of node just doesn't make sense.

Project Impact & Opinions

By blessing a specific project, you'll be blessing a specific approach. In my personal experience, there are two major opinions driving usage of any of the version managers. It boils down to simplistic vs deep workflow integration. Individuals seem to like deeper integration while teams like less (or the ability to customize their own workflow, given a set of simplistic tools).

Examples From my Experience

When I made NVM4W, my goal was to mimic the experience of replacing node with a newer/older version (i.e. uninstall/reinstall) on demand. I didn't want the tool to influence how developers wrote or deployed apps. Since NVM4W was made well after nvm, and intentionally more minimalistic, there were lots of questions about cherry picking versions for a specific process or terminal, .nvmrc files, etc. Instead of focusing on which version of node was installed, feature requests started circulating around managing the entire dev environment, app development/dependencies, DevOps tasks, etc. I've also had equally divided feedback arguing version management should be system-wide vs per-process.

Managing npm modules across versions is a pain due to sheer size/quantity. One corporate user mentioned his workstations took nearly 30 minutes to boot up because he kept multiple versions of node installed, each with a very healthy collection of npm modules, all within a roaming profile being copied over a slow internal network. This has lead to several enthusiastic conversations from people who want a "shared global node_modules" to reduce the footprint problem, as well as several who are adamantly opposed to that.

---

Sorry for the novel. This is just a brain dump and some initial gut reactions. If there is anything I can offer in this process, I'd be happy to. I would love to see version management addressed in some sort of official capacity.

[brodybits]

I would rather see a version manager that supports both Windows and non-Windows platforms and is primarily in JavaScript, such as https://github.com/jasongin/nvs (thanks @joshgav).

[ljharb]

@brodybits long term, that's probably the best direction, but there needs to be lots of iteration on featuresets so as to address use cases, and provide migration paths.

[joshgav]

The TSC reached consensus to start a discussion group bringing together the various maintainers and stakeholders for version management tools for Node - basically everyone on this thread 😄 - with a goal of quickly providing recommendations and a roadmap for version management in core. Items this group should tackle now include if/how to converge on a single tool, if/how to distribute or bundle with Node, how to support all platforms, etc.

The TSC would like us to have this roadmap ready to discuss by their next meeting, Thursday 11/17. Then they can make a decision on whether to accept "version management" as one of core's responsibilities.

To this end, we now have a repo at https://github.com/nodejs/version-management. I'll set up the boilerplate stuff there and a doc or two and look to you all to open issues etc. for further discussion.

Thanks!!

[marcelklehr]

@coreybutler we could meet here: https://gitter.im/marcelklehr/nodist - although I think, it might be better to put our efforts into the new WG for now, at least until it has reached an outcome and the TSC has reached a decision.

[ljharb]

fwiw, I think any long term project should be written in JS if possible to maximize contributors and accessibility, but that can be part of the discussions we have.

[coreybutler]

@marcelklehr - agreed... the new repo was setup right after I made that comment. See you in the WG!

[joshgav]

To help in continuing this thread, I'm bringing over this discussion which followed the Version-Management Discussion Group Meeting on 2016-12-01.

---

What about nvm being in the Foundation?

• Should only projects actively supported by core be in Foundation?
• Bring them all in? Not sustainable.
• So if something is to be in core/Foundation, would need to be one, and would
  need to follow documented patterns and standards.
  • Should it be nvm? Maybe, still too early to tell. First come to consensus on
    standard patterns.

@ljharb > why only one? This makes no sense to me. Bringing in two, or three, in no way is a slippery slope to "all".

@joshgav> @ljharb the key new understanding we reached in our discussion Thursday was that any project in the Foundation needs to be actively supported by the Foundation. That means at least engineers maintaining and updating it, but more than that indicates some degree of assumed responsibility for us here in core; perhaps to address bugs and security issues, perhaps something else. /cc @mikeal @rvagg for further thoughts.

Based on that understanding it's probably not sustainable to support more than one in core, so we want to be conscientious about what that one is.

Does that help explain why it seems "only one in the Foundation" should be our goal? Do you think we could support more?

[ljharb]

@joshgav I absolutely think we can support more, because more are already being supported - just not by the foundation. Adding projects to the Foundation does not move the total maintainence burden, it lessens it because more people might be able to help lighten the existing maintainers' load.

If nvm enters the foundation, I'm not going to suddenly alter the amount I maintain it - nvm being in the foundation adds, initially, precisely zero cost to the Foundation itself.

Even now, though, not in the foundation - if nvm suddenly needed maintenance I was unable to provide, the Foundation would probably have to step in to serve those users and provide graceful migration instructions anyways - because so many node users already rely on nvm, either directly or via travis.ci - so whether it lives in the foundation or not doesn't impact how much work the foundation might potentially have to do.

[mikeal]

A few things that are hard to get from just notes.

1. The Node.js Foundation is backing away from being an umbrella.
   1.1. Projects in the foundation are those directly tied to core.
   1.2. Concern about "blessing" a project and ruining ecosystem competition is a big concern as well.
2. The Node.js Foundation is partnering with the JS Foundation to make it a great home for Node.js projects.
   2.1. The JS Foundation is setup, structurally speaking, to be an umbrella.
   2.2. The JS Foundation can provide better support for projects as that is their primary mission, where ours is Node.js itself, and we can help the JS Foundation to support projects critical to Node.js.

If the maintainers of nvm think it needs to go into a foundation then we believe them. The question of entering the Node.js Foundation was greater than just "does the project need a home" and the answer from the versioning group seems to be that it shouldn't go into the Node.js Foundation but if the maintainers need a home for it the JS Foundation is an option.

I'm willing to help get it into the JS Foundation and support it. We aren't trying to pass the buck, we have a partnership so that we can continue to support important projects that just don't belong, structurally speaking, in the Node.js Foundation.

[ljharb]

@mikeal the JS foundation doesn't make much sense to me for a non-JS project, but I'm fine with putting it there if that's what the node foundation has decided - although I can't understand why it would want to "back away" from being an umbrella, since that's what foundations are for imo.

[mikeal]

@ljharb projects that improve the web or the overall JS ecosystem are a good fit in the JS Foundation. Appium is a good example which has code and bindings in a bunch of languages but is fundamentally for testing the web.

We are still working on better documentation on how the Node.js Foundation is structured but if you compare it with the JS Foundation you'll see why it's a better fit.

The Node.js Foundation was started as a home for Core and for merging io.js. The initial structure has solidified somewhat and our attempt at re-structuring as an umbrella didn't work. The JS Foundation learned from what we did and designed a much better structure for bringing in and supporting many projects. They also adopted our governance ideas, in some cases verbatim, so they've been able to take ideas from our success as well as our failures in terms of structure.

[ljharb]

If the JS Foundation has a better structure, could the Node foundation not adopt it? Or perhaps should the Node Foundation be renamed to the Node Core Foundation? Will express and so forth be moved to the JS Foundation?

[mikeal]

@ljharb it has proven difficult to adopt structural changes while also supporting Core, its contributor growth, and the growth of the Node.js user base. We have a lot to do already and all under one roof, the idea of taking on more concerns a lot of people who think it will lead to a lack of focus.

Express can join the JS Foundation if that is their preference. They have some autonomy so we can't make them join another foundation if that isn't what they wish.

[creationix]

In my opinion, the current real value of nvm is the CLI interface that has become hugely popular. I've seen some cloud providers (such as redhat openshift) even write nvm clones that mirror a subset of the functionality.

For cross-platform support I agree that something written mostly in JS with shims implemented in various shells (sh, fish, cmd, powershell, etc) would be ideal technically.

There were still npm competitors when it became part of core, but it was obvious that npm was the de-facto standard for most people. As far as I can tell nvm has reached similar status, but getting hard numbers is hard. I've just been surprised the number of infrastructure places I've seen it used or cloned.

[joshgav]

To wrap this conversation per the last TSC meeting, the recommendation of the version-management group, which brought together @ljharb and authors of other popular version managers for Node, was that Node core should not bring in and support a version manager without first defining requirements for such a tool and ensuring whatever is brought in meets those requirements. The TSC accepted that recommendation.

On the other hand, the TSC agreed that the version-management group created for this discussion should remain active and continue to seek consensus on those requirements; and once they are defined may recommend that the Foundation support an updated nvm or other project.

[jasnell]

Given the most recent status update, and given that the investigation is underway, there's no reason to keep this issue open. Closing. If anyone feels it is necessary to keep it open, please reopen.

[DanielSundberg]

Where can I follow this discussion now when this issue is closed?

[Trott]

@DanielSundberg https://github.com/nodejs/version-management (although it looks like there hasn't been much activity since December)

[Trott]

@DanielSundberg Also, perhaps, specifically this: nodejs/version-management#10