fnm install usability

[rotu]

fnm install doesn't make it obvious what versions are available.

1. I would expect the version argument to have some examples in fnm install --help. (e.g. fnm install lts/latest, fnm install lts/fermium).
2. I expect fnm install lts and fnm install latest to work. It seems odd that the --lts and --latest options are flags, given that they fill the same role as the VERSION argument.
3. Trying to install a missing version does should give some hint as to what's available. fnm install lts/18 merely prints "error: Can't find relevant LTS named 18". It would be nice for it to show either what versions are available or recommend fnm list

[polarathene]

fnm install doesn't make it obvious what versions are available.
I would expect the version argument to have some examples in fnm install --help.

$ fnm install
error: Can't find version in dotfiles. Please provide a version manually to the command.

# Top part of the help output:
$ fnm install --help
Install a new Node.js version

Usage: fnm install [OPTIONS] [VERSION]

Arguments:
  [VERSION]
          A version string. Can be a partial semver or a LTS version name by the format lts/NAME

Partial semver or LTS version name in format lts/NAME is fairly clear?

It could mention fnm list-remote perhaps, although the default output is verbose, rather than collapsing semver to latest majors? 🤷‍♂️

Filtering the output to something like this would probably be convenient (fnm list-remote --lts perhaps, or similar approach that works without the LTS name):

# Filters to only lines with an LTS name,
# flips the order (to prefer latest version),
# sorts by the right-side (LTS name) as unique field
# Flips output of sort so the latest LTS is at the top:

$ fnm list-remote | grep '(' | tac | sort -k 2 -u | tac
v20.9.0 (Iron)
v18.18.2 (Hydrogen)
v16.20.2 (Gallium)
v14.21.3 (Fermium)
v12.22.12 (Erbium)
v10.24.1 (Dubnium)
v8.17.0 (Carbon)
v6.17.1 (Boron)
v4.9.1 (Argon)

---

2. I expect fnm install lts and fnm install latest to work. It seems odd that the --lts and --latest options are flags, given that they fill the same role as the VERSION argument.

Not quite. lts / latest would be similar to aliases in other commands (which --lts does create the lts-latest alias for).

The problem with that usage elsewhere is the major version they refer is much more prone to shifting to a newer release where breaking changes may not be expected, or the user mistakenly thinks they're using the latest lts or latest version of Node, when the alias continues to point to the original version installed it was added for.

As option flags the semantic meaning is a bit more distinct, and would make more sense to use in those other commands (and thus fnm install ... too for consistency in UX) as it can imply that they're more dynamic and refer to the latest release of Node or LTS when queried, unlike an alias.

---

3. Trying to install a missing version does should give some hint as to what's available. fnm install lts/18 merely prints "error: Can't find relevant LTS named 18". It would be nice for it to show either what versions are available or recommend fnm list

fnm list would only be useful if you already have that installed? Not sure how that'd be helpful with fnm install, perhaps you meant fnm list-remote?

In your case, instead of using the LTS name, you already know the version number, so just using the major semver fnm install 18 would have done what you wanted?

---

TL;DR

• --help provides a fairly clear expectation? Examples may be helpful but it'd seem more of an issue with the error message for invalid values.
• lts / latest may seem intuitive with fnm install, but effectively an alias elsewhere (and a PR open to have --latest set/update the latest alias). Adopting --lts + --latest in other subcommands is probably a better UX overall.
• Invalid version error should reference what a valid version looks like (by displaying the same version line from --help) and directing the user to the fnm list-remote command for querying available LTS names and/or Node versions.
  • There are two PRs open for filtering + sorting output and --lts specific filter, but neither seem to filter out the prior versions of a major semver release series.

[Philzen]

Not sure if this is related, but i assume b/c there seems to be a missing link between actual version numbers and codenames. In my project i have an .nvmrc containing

lts/hydrogen

Although nvm list gives multiple v18 versions, whenever i cd into the project's directory i get:

Can't find an installed Node version matching lts-hydrogen.
Do you want to install it? answer [y/N]: 

which blocks my workflow. When confirming it goes to

Installing Node v18.20.2 (x64)
warning: Version already installed at "/home/me/.local/share/fnm/node-versions/v18.20.2"
Enabling corepack for Node v18.20.2

[SoonIter]

Although nvm list gives multiple v18 versions, whenever i cd into the project's directory i get

same issue with #1035 (comment)

➜ fnm use
Can't find an installed Node version matching lts-iron.
Do you want to install it? answer [y/N]: y
Installing Node v20.13.1 (arm64)
warning: Version already installed at "/Users/usr/Library/Application Support/fnm/node-versions/v20.13.1"

[Philzen]

@SoonIter i found a solution, respectively workaround. The fact that it would keep re-installing i.e. lts/hydrogen found in an .nvmrc over and over again is due to no alias being set for that name.

This is what nvm list gave before for me:

$ fnm list
* v16.20.2 lts-gallium
* v18.18.0
* v18.18.1
* v18.18.2
* v18.19.0
* v18.20.1
* v18.20.2
* v20.7.0 default
* system

So, assigning an alias here is the solution. In my case, for lts-hydrogen it is as simple as selecting a particular version that i want to alias against and tell fnm to use that:

$ fnm alias v18.20.2 lts-hydrogen

Now, when using fnm in a project directory where it encounters an .nvmrc with lts-hydrogen it will no longer ask to download it and activate v18.20.2 straightaway.

This can be verified by checking fnm list again, which now shows the alias:

$ fnm list
* v16.20.2 lts-gallium
* v18.18.0
* v18.18.1
* v18.18.2
* v18.19.0
* v18.20.1
* v18.20.2 lts-hydrogen
* v20.7.0 default
* system

---

Of course, it would be preferable – if not a minimum requirement for seamless DX (in which i agree with @rotu) – if this alias would be set automatically on first download of any lts version.

Ideally, it would also hint about newer minor releases as it becomes aware of them and offer to install and update the LTS aliases accordingly, however that may be out of scope of this bug report and an advanced nice-to-have feature for the future.