Which Switching Scopes to support by an official solution?

[marcelklehr]

Before we dive into discussions on which language/framework to use, I think we should have a clear set of features that we want to offer.

[marcelklehr]

There's quite a few different scopes for setting a version requirement, that I can think of:

• system-wide
• per user
• per terminal
• per directory

pro UX

I've found per terminal and per directory to be the most useful, as per-terminal is imperative-ish but temporary (if you want to try your app with a different version), while per-directory is declarative and persistent (the default version per app). I think the great advantage of per-directory settings is that you don't need to remember to change your global node version when your change to another project, the switching is automatic, but defined in a declarative fashion per directory, just like your dependencies, and your build/test scripts, (possibly in the package.json, where there is already a corresponding field). IMO that's very powerful.

pro simplicity

However, the downside of this feature is that it's not easy to implement consistently across operating systems. It could also be argued that, rather than wait for a high-end solution to be built, it's better to work on a simple solution that may require more cognitive load from the down-stream developer.

I see both sides while leaning more towards pro UX

[digitalinfinity]

@jasongin put together a table at https://cdn.rawgit.com/jasongin/cf9f64dd2739d78412bb9410701bf166/raw/69d48e0774f43280763eb7bb7175e930ab3e9f33/NodeVersionManagers.html comparing the various scopes settable by current version managers. It might be helpful to this discussion.

[jasongin]

the downside of this feature is that it's not easy to implement consistently across operating systems

It's not so bad. For nvs I'm currently developing automatic per-directory switching. (It already supports the other 3 scopes.) For Windows PowerShell I've got it working now by hooking PowerShell's prompt function. I plan to implement the equivalent for POSIX using the same approach as nodengine. Windows Command Prompt does not offer any integration point though.

Of course any automatic switching feature should be optional, as not everyone wants things to happen without an explicit command.

[marcelklehr]

@jasongin Interesting! I implemented per-directory switching via a binary shim in nodist, because I didn't want to / couldn't hook into cd.

[coreybutler]

This is a good breakdown. The first two scopes seem to be the common denominator. The third and fourth seem more a matter of opinion.

I also see the value of both sides, but I lean pro simplicity.

[ljharb]

@coreybutler nvm is entirely the third, so in no way is it just a "matter of opinion".

In fact, the second is the one that nobody seems to be really addressing currently - n is systemwide (across users), nvm is per-shell (within a user), nave is per-subshell (within a user). The fourth is dealt with any non-systemwide solution that includes auto version switching on cd (which you can do with nvm, but is not done by default to avoid being instrusive)

[coreybutler]

@ljharb - I respectfully disagree. Before version managers existed, the only choices were the first two. In other words, you don't need 3 & 4 to accomplish version management. nvm-windows and n prove this by lack of 3 & 4. I'd argue Tim created the 3rd & 4th when he released nvm.

nvm-windows does support per-user, but defaults to systemwide. It's an option in the installer.

[jasongin]

@coreybutler I think the popularity of nvm (and nave to a lesser extent) proves there is a very significant user base who prefer (or need?) to have per-shell versioning.

I don't think a single switching mechanism or just one (or even 2) of those four scopes will ever satisfy everyone's needs. I'd suggest that any converged solution we work on must cover at least the first 3 of those scopes, and ideally all 4.

[ljharb]

@coreybutler you may be right that the creation of nvm created the third and fourth - but they are now, unarguably, absolutely critical use cases that must not be ignored.

[coreybutler]

@ljharb - I'm not suggesting we ignore options 3/4, I'm suggesting they be optional features that can be turned on. In other words, the default should only enforce what's actually necessary to perform version management, with the option to turn on extra features.

[ljharb]

There are a number of benefits with having the default be per-shell instead of being systemwide.

[marcelklehr]

I agree that strictly speaking "you don't need 3 & 4 to accomplish version management" or version switching. However, I believe that a version manager (just as any tool; especially an official one) should address the needs of its users.

To elaborate on why I'm leaning towards UX: I'd argue that while downstream developers might want a way to somehow quickly uninstall one and install another version when they work on another project (which is equivalent to 1), what they actually need is a way to use multiple versions at once or even set a default version per project.

I also agree that 1/2 make sense in certain cases and should thus be part of an official solution, however I think 3/4 should be provided as well.

@ljharb Could you elaborate on the benefits of 3 to be the default?

[rmechamatadobe]

By deciding not to implement the ability to run various versions of node in different console shells you are persuading a whole group of developers to move off the Windows platform as their development environment. Remember developers are using your tool, not your standard end user. We don't mind having to configure things a bit more if they make our overall lives easier.

[ljharb]

@rmechamatadobe I’m not sure what you mean - node offers no version switching capabilities at the moment on any platform, and there are multiple version managers available that work on windows. nvm (on WSL), nvs, nvm-windows, fnm, just to name a few.

[rmechamatadobe]

Sorry I meant to say “nvm switching node versions”. So in Mac OS you can go to one shell and run “nvm install v8.1.2 && nvm use v8.1.2” and then go to another shell and run “nvm install v10.2.1 && nvm use v10.2.1” and run two different versions of node at the same time the two shells.

[ljharb]

@rmechamatadobe that’s dealing with one specific version manager, which a) isn’t this repo, and b) works on windows if you’re using WSL.

[rmechamatadobe]

@ljharb Oh man, that's embarrassing :). My bad, I'm so sorry. I thought this was the git repo for the Windows NVM project.

[coreybutler]

@rmechamatadobe I replied to the comments you left in the nvm-windows repo.