Nvm: Should io.js be removed from nvm ls? Now that it is merged with node again

[geoyws]

Since io.js isn't going to be developed anymore.

[ljharb]

Neither is "unstable", or node < 0.10, but those are still in the list :-)

Things still need to be tested in io.js, since people may be running it in production, and it's useful to test things in historical engines.

I may, in some future version, remove "stable", "unstable", and "iojs" from displaying in the list (when they'd otherwise be N/A), but it won't be any time soon.

[geoyws]

Righty'os. Thanks for the quick reply. ^^b

[laoshaw]

with nvm 0.33.7 and nodejs 8.9.3 when I do 'nvm list' I still see "iojs N/A(default)", why is it still there? also see "lts/argon v4.8.7, lts/boron v6.12.2", which I no longer install or has uninstalled, why keep the staled content in nvm ls all the time?

[ljharb]

They’re install options, and they conflict with user aliases. How would you know they were there if you hadn’t yet installed one of those versions?

[whyboris]

It's 2019 and we still have iojs polluting our nvm ls 😢
Since virtually no one uses this, could it not be there?
The few people who want iojs can simply add the alias - it's easy enough 👍

[ljharb]

Without the default alias, there’d be no way to refer to iojs versions specifically. I could hide it from the output by default, but then how would users know it’s there behind an option?

[subfuzion]

virtually no one uses this

Literally no one uses this.

I will donate $100 to any charity of your choice if there is a single organization actually running iojs in production (that they didn't forget about) and the organization will actually admit to it. It is time to remove this from the output. No one will complain. NO one.

[ljharb]

@subfuzion I use this on all of my 100+ modules for testing; using old versions of node is a valuable proxy for testing in old browsers even if nobody is using that node version in production.

In other words, even if zero people on the planet are using io.js in production, there are many millions of people using equivalent web browsers.

[subfuzion]

@ljharb As someone who was a member of the io.js Evangelism Working Group, I really did care about io.js back in 2015. I really don't get your argument about web browsers, but regardless, all of the io.js features are available in Node v4 and later. Sorry, but io.js is an ancient, dead artifact that has zero relevance aside from being an interesting anecdote in Node's history.

It should be buried behind a flag to enable and anyone who actually cares about it can google for the flag or read about it on the nvm page. No one will complain.

[ljharb]

It absolutely has relevance - there are browsers in active use that have similar featuresets to io.js v1, v2, and v3. Ensuring projects work in these node versions ensure that they won't break in browsers that lack node 4's features.

In other words, I'm saying the benefit is that they LACK features, for testing purposes.

[subfuzion]

Sorry, but that argument isn't really making much sense for me. What does io.js have to do with browsers? You mean browserified code circa 2014/2015? There was a six month window where iojs officially forked from node at the end of 2014 and then the projects were merged back half a year later. Aside from your use case (which is a testing use case that doesn't otherwise prove the need for iojs), you're saying that there exists an organization or user out there that is actively concerned about testing code that runs on some version of node between v0.12.18 at the end of 2014 and v4.0.0 around May of 2015 when the projects re-converged?

And in any case, I'm not proposing removing support, just hiding it behind a flag. Are you are saying that a user would be frustrated if they had to use a flag (e.g., nvm ls --include-iojs or nvm alias --include-iojs) when using the tool today, half a decade later? Because they would have trouble discovering that flag or because it would break their CI builds?

Sorry, I'm just not seeing it. I suppose it's not worth wasting time discussing ad nauseum, but it's hard to see a valid rationale for preserving the current behavior.

As is, it looks like an error and I've had to explain this too many times to people in demos. Hard to see the value of this today, but perhaps changing the color to gray would make it less objectionable.

[ljharb]

Not node - chrome, and any other browser version that has similar language level support.

[subfuzion]

Sure, but you are really going out of your way to ignore my points / questions? I really don't see this as a valid rationale, but why not address the other questions I've raised? Why can't this be hidden behind a flag? Who will this hurt exactly? Or at least why not change the output so it doesn't look like an error?

[ljharb]

@subfuzion they've already been addressed upthread.

[subfuzion]

"I may, in some future version..." is quite vague. You "may" because you really don't have time for it now, but you're open to PRs from others? Or is there some other criteria? Some more time? It's your prerogative ... it's open source (nvm is a great tool that has served the Node community well for years) and you don't owe anyone an answer who hasn't been an nvm contributor, but the vagueness certainly does come across as arbitrary.

It's not that I want to keep bikeshedding in this thread, but I think the issue reflects a more general UX problem. Perhaps instead of continuing the conversation here, it will be best to open a separate issue. So I'll just summarize the observation that it is not unreasonable to expect the following:

nvm ls - show me what I've got installed, their aliases, and indicate what the current version is. "If you want to see what versions are installed..."

Simple. I have three versions of Node installed on my system. The command does what it says it does in the documentation and what most people expect it to do. The ls command lists what you have, not what you don't have.

nvm alias - show me all the aliases, predefined and mine, and the versions they are pointing to, or N/A if not installed:

Cool, I do expect to see iojs and all the other aliases. I'm not surprised or confused by this at all ... other than the ~erroneous~ somewhat ambiguous (default) indicators and the lack of visual distinction or segregation between predefined aliases and the ones I created (v10 and v11), but those are different UX issues...

[ljharb]

Those non-erroneous default indicators are the visual distinction/segregation between predefined aliases (default ones) and the ones you created.

nvm ls currently just calls directly into nvm alias.

It sounds like you’re proposing an option on nvm alias that only lists resolvesble aliases, and that nvm ls provides this option when it calls into nvm alias. This seems reasonable. What do you think should happen with “node” and “default” when either of these is unresolveable? Do you think it makes sense for these to be special cases and always be shown? If so, what would you name/how would you describe the option so the exceptions are clear?

[subfuzion]

Ok, I see my misunderstanding about (default). But in that case, the word is literally being used incorrectly. Among a set of options, the default is what you get when you don't select something; so there is a default alias (or version), but all of these aliases cannot simultaneously be defaults. One can argue that there is a default set of predefined aliases," so therefore this indicates membership in the default set, but that would only mean that the default set of aliases is selected when you don't choose among a set of sets. Sigh. In any case, without getting any more pedantic, the value itself is questionable, as noted below under multiple versions of Node.

To answer your question, if there is no version of Node installed at all (including no "system" version), I think it's reasonable to show nothing in the output or else to show a minimal amount of helpful information. I don't expect to see the default alias until there is more than one version of Node installed where default than becomes relevant, but as I will argue below, I don't think the term "default" should be used in any case, whether to indicate the active version of Node or to indicate predefined aliases.

No Node.js on the system

One could legitimately argue that the ls command should show nothing, but that's probably too radical of a change at this point and it's not very helpful either.

$ nvm ls
$

This is what I currently see on a new instance with no Node.js installed and a fresh installation of nvm:

$ nvm ls
            N/A
iojs -> N/A (default)
node -> stable (-> N/A) (default)
unstable -> N/A (default)

I think this is reasonable, although it might be better not to show a line with N/A all by itself, and I do think signal-to-noise can be enhanced (we'll get to that).

The alias command output looks good also.

$ nvm alias
iojs -> N/A (default)
node -> stable (-> N/A) (default)
unstable -> N/A (default)

However, this is one case where perhaps it's actually effective to print all of the standard aliases, not just a subset, so that the user then has an idea of what can be installed. Just a thought...

$ nvm alias
node -> stable (-> N/A)
unstable -> v0.11.16 (-> N/A)
iojs -> iojs-v3.3.1 (-> N/A)
lts/* -> lts/dubnium (-> N/A)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.17.0 (-> N/A)
lts/carbon -> v8.15.1 (-> N/A)
lts/dubnium -> v10.15.3 (-> N/A)

One version of Node.js (the system version)

As soon as I yum install a system version of Node, nvm ls prints the following:

$ nvm ls

->       system
iojs -> N/A (default)
node -> stable (-> N/A) (default)
unstable -> N/A (default)
lts/* -> lts/dubnium (-> N/A)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.17.0 (-> N/A)
lts/carbon -> v8.15.1 (-> N/A)
lts/dubnium -> v10.15.3 (-> N/A)

This is a lot more than when there was no Node installed at all, but all I really expect to see now is something compact, like this:

$ nvm ls
-> system (v0.10.48)

The node version is not resolved since the latest version of Node is not installed. The following output might be very helpful:

$ nvm ls
-> system (v0.10.48)

You do not have the latest stable version of Node.js installed.
Run "nvm install node" to install the latest stable version (v11.12.0).

More than one version of Node.js

As soon as I install another version using nvm I see:

$ nvm install node
...
$ nvm ls
->     v11.12.0
         system
default -> node (-> v11.12.0)
node -> stable (-> v11.12.0) (default)
stable -> 11.12 (-> v11.12.0) (default)
iojs -> N/A (default)
unstable -> N/A (default)
lts/* -> lts/dubnium (-> N/A)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.17.0 (-> N/A)
lts/carbon -> v8.15.1 (-> N/A)
lts/dubnium -> v10.15.3 (-> N/A)

Ok, I understand now why default -> node appears since there is more than one version of Node available now. If we are going to use "default" to indicate the predefined aliases, however, I wouldn't use "default" here. There is already an arrow pointing to the version of Node currently in use, so why put "default" at all where one expects aliases?

Furthermore, all those extraneous (default) annotations also don't really help me reason correctly about the output. They are highly misleading since in this example many of the lines with the annotation coincidentally point to the "default" version of Node in use -- leading me to believe that some of those lines (iojs, unstable) are erroneous.

Using "default" only to indicate predefined aliases is still problematic, however. I didn't have any problem reasoning about predefined aliases, but the term "default" literally means something different. It is being used incorrectly in this context to indicate multiple names that were predefined to point to Node versions. "Default" is literally what you get when you don't choose an option. The following reflects dispensing with "default" altogether.

$ nvm ls
->     v11.12.0
         system
node -> stable (-> v11.12.0)
stable -> 11.12 (-> v11.12.0)

It is intuitively obvious that v11.12.0 is the version of Node currently in use in this shell. From the above, I infer that I can also select "system" as an alternative (it would be great if system also showed the version in parentheses, or some other way).

Here's a different take on the output:

$ nvm ls
-> v11.12.0 [node, stable]
   v0.10.48 [system]

I'm sure this can be improved, but the succinctness already enhances signal-to-noise more over the current output. It's unambiguous about the active version of Node and while I might wonder the first time I use nvm, it's not a big leap for me to recognize at some point that I can associate those names as aliases displayed by the nvm alias command and supported by the nvm use command. Furthermore, it's printing for me what anyone who uses the ls shell command readily relates to -- it's what I have, not what I don't have.

It's true that the output doesn't reveal the existence of other aliases, but once I want to install another version of Node, I'll soon discover that the nvm install command can use standard and user-defined aliases, not just explicit versions, and I'll eventually become aware of the nvm alias command as well.

Anyway, long comment on an issue about removing iojs from output! Hope this is constructive, but maybe it's better to open a separate issue dedicated to a more general topic about evolving the command UX. I'm happy to do that if you prefer.

[ljharb]

This was a long comment so I'll try to respond to your points; if I miss one please call me out.

The first time nvm connects to nodejs.org, it populates all the LTS aliases - so nvm alias will show all those at that time.

An error message can't know what the latest available version is without making a network call, and nvm ls does not and should not make a network call - so I don't think we should be making any messaging talking about "latest". A stderr message in nvm ls when there are zero nvm-managed nodes available might be a reasonable change, however - please file a new issue or PR that's just for that change, so we can iterate on it in isolation :-)

Regarding the confusion - I do want to change (default) to (built-in alias) or similar at some point; I hope that would address that part of the problem?

[jsejcksn]

I think it is more sensible to provide a flag for more verbose output than to need to provide a flag for less verbose output. I agree that the output for nvm ls --no-alias should be what we get from nvm ls and that we should need to provide a flag (like nvm ls --alias) for the combined output.

> nvm ls --no-alias
->     v12.16.3
        v14.1.0

The output of nvm ls feels cluttered:

> nvm ls
->     v12.16.3
        v14.1.0
default -> lts/* (-> v12.16.3)
node -> stable (-> v14.1.0) (default)
stable -> 14.1 (-> v14.1.0) (default)
iojs -> N/A (default)
unstable -> N/A (default)
lts/* -> lts/erbium (-> v12.16.3)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.17.1 (-> N/A)
lts/carbon -> v8.17.0 (-> N/A)
lts/dubnium -> v10.20.1 (-> N/A)
lts/erbium -> v12.16.3

What command can I use to get output that only shows what's relevant to my installation and excludes everything else (e.g. the N/A entries)? Like this:

->     v12.16.3
        v14.1.0
default -> lts/* (-> v12.16.3)
node -> stable (-> v14.1.0) (default)
stable -> 14.1 (-> v14.1.0) (default)
lts/* -> lts/erbium (-> v12.16.3)
lts/erbium -> v12.16.3

[ljharb]

A stderr message in nvm ls when there are zero nvm-managed nodes available might be a reasonable change, however - please file a new issue or PR that's just for that change, so we can iterate on it in isolation :-)

Nobody's filed an issue or PR yet.

we should need to provide a flag (like nvm ls --alias) for the combined output

One exists - nvm ls --no-alias works fine.

What command can I use to get output that only shows what's relevant to my installation and excludes everything else

Sounds worth filing this as a new issue, or better, a PR with tests :-) (in other words, an option that hides any alias, local or built in, that doesn't resolve to a version)

[jsejcksn]

@ljharb The first part was the focus of my comment:

I think it is more sensible to provide a flag for more verbose output than to need to provide a flag for less verbose output.

[ljharb]

I'm not sure I agree. The most discoverable command should list the most things, otherwise how will people know these aliases even exist in the first place?

The default should be to show everything, and flags should be used to narrow/filter - this is how most tools I've used work, including every command in nvm.

[jsejcksn]

otherwise how will people know these aliases even exist in the first place?

Like with all products: reading the manual/documentation

[ljharb]

I've stated my position: the default should be verbosity, because more information is better for newcomers.