Let's say you have Node 8 installed, should fnm use lts/* use it, or in return say "you don't have Node 10 installed"?

The former is possible, by traversing on every lts-* alias and choose the latest version between them. But I think that's not what you'd expect for as a user. The latter is also possible but probably require a network call on use, which is not ideal and will make things potentially slow.

I think that neither are good options because there are breaking changes between LTS versions (I have seen projects that bumping Node versions to 10 was problematic.) and therefore its okay to only support the lts/SPECIFIC_VERSION syntax. If we decide that we don't support it (until we find a performant and easy-to-grasp way to handle it), we should throw an error when seeing lts/*, and saying that we don't support - and maybe link to this very issue.

What do you think?

I think explicitly stating in the documentation that fnm does not support lts/* due to the authors/maintainers believing it is not a safe/good practice + throwing an error when a user attempts to use fnm with an .nvmrc containing lts/*, informing the user that this isn't supported, is probably okay.

I just made this issue because the docs stated that fnm was fully compatible with .nvmrc, but then I found this edge case where it's not.

However, if you do want to support it, I believe the 2nd of the two options you listed, in return say "you don't have Node 10 installed", would be closer to how nvm works, as lts/* is supposed to just use the most recent lts version available.

I am not familiar with the internals of fnm, but wouldn't the slowness only be introduced in the specific case of where lts/* is detected in the config file? I imagine the process would be something like:

-> `lts/*` is not detected
   -> `fnm` continues to work as it does now
-> `lts/*` is detected
  -> first, make a network request to discover the latest node LTS available
  -> then, check the user's installed versions of node
     -> if installed, use this version
     -> if not installed, prompt the user with a message like:
        "The current LTS is v_._._, which you do not have installed. Install v_._._? Y/N"

As @dcodeIO has mentioned on Twitter (or maybe I inferred it from that thread), a good case for lts/* is nightly builds on CI. Even then, I probably wouldn't use it — I'd rather have a specific lts version mentioned, instead of be surprised when the version bumped.

I am not familiar with the internals of fnm, but wouldn't the slowness only be introduced in the specific case of where lts/* is detected in the config file? — @joshburgess

It can be! The only thing left to understand now is how to make the most performant latest lts checks.
I just found https://nodejs.org/dist/index.json and we can filter by lts: true and then sort by semver 😄 This file can be cached in the future.

use can work by looking for lts-* aliases, sorting by semver and using it

I use lts/* on all my linting builds, as well as npx aud audit runs. It doesn’t matter what version of node they run with as long as it’s late enough, and it’s more reliable than using latest.

How can you setup to use lts version? I tried fnm install lts and it doesn't work.

Right now, use a specific lts version, like fnm install lts/dubnium. I need to work on making fnm install lts/* work. Then, we could practically support fnm install lts that would be the same, or fnm install --lts (that I believe nvm does?)

nvm supports both; double dash for the command line, the slash form is for config files.