🦋 Changeset detected

Latest commit: a436254

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Might be nice if it can omit earlier releases, most of the time you may only be interested in seeing a list of the latest versions sorted by major (or just LTS).

For example, this would probably make for a nicer fnm list-remote --lts sort of filter (related is this --lts filter option PR):

# 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)

Cool idea! I think we can receive a semver range like “install” and “use”. Should not be hard to implement too. Are you interested in doing so?

(A nice way of learning Rust)

Ah now I see you know Rust haha

Cool idea! I think we can receive a semver range like “install” and “use”. Should not be hard to implement too. Are you interested in doing so?

@Schniz I've refactored it to take UserVersion, so now it accepts the same version specifications as install and use 👍

Might be nice if it can omit earlier releases, most of the time you may only be interested in seeing a list of the latest versions sorted by major (or just LTS).

@polarathene I've added support for filtering LTSes with --lts and optionally specifying the LTS name, I think adding major version support to the option won't be necessary because just using the filter argument would work.

Edit: Your example picks out the latest versions from each LTS, should I make that the behavior here as well?

@polarathene I've added support for filtering LTSes with --lts and optionally specifying the LTS name

That's great, thanks! ❤️

I think adding major version support to the option won't be necessary because just using the filter argument would work.

Edit: Your example picks out the latest versions from each LTS, should I make that the behavior here as well?

That might be nice to have too. I suppose it should be an additional flag like --latest?

I assume the current PR would output something like:

$ fnm list-remote --filter 20
v20.0.0
v20.1.0
v20.2.0
v20.3.0
v20.3.1
v20.4.0
v20.5.0
v20.5.1
v20.6.0
v20.6.1
v20.7.0
v20.8.0
v20.8.1
v20.9.0 (Iron)


$ fnm remote-list --lts iron
v20.9.0 (Iron)


$ fnm remote-list --filter 20 --lts
v20.9.0 (Iron)


$ fnm remote-list --lts hydrogen
v18.12.0 (Hydrogen)
v18.12.1 (Hydrogen)
v18.13.0 (Hydrogen)
v18.14.0 (Hydrogen)
v18.14.1 (Hydrogen)
v18.14.2 (Hydrogen)
v18.15.0 (Hydrogen)
v18.16.0 (Hydrogen)
v18.16.1 (Hydrogen)
v18.17.0 (Hydrogen)
v18.17.1 (Hydrogen)
v18.18.0 (Hydrogen)
v18.18.1 (Hydrogen)
v18.18.2 (Hydrogen)


$ fnm remote-list --lts
// ... many more
v18.17.1 (Hydrogen)
v18.18.0 (Hydrogen)
v18.18.1 (Hydrogen)
v18.18.2 (Hydrogen)
v20.9.0 (Iron)

Where --latest logic would be fairly straight-forward (take the last item from all_versions after sorting, but before reverse()), except for the final one (latest of each LTS):

$ fnm list-remote --filter 20 --latest
v20.9.0 (Iron)

$ fnm remote-list --lts iron --latest
v20.9.0 (Iron)

$ fnm remote-list --filter 20 --lts --latest
v20.9.0 (Iron)

$ fnm remote-list --lts hydrogen --latest
v18.18.2 (Hydrogen)

$ fnm remote-list --lts --latest
// ... same with earlier LTS
v18.18.2 (Hydrogen)
v20.9.0 (Iron)

Differs from UX of fnm install --lts / fnm install --latest / fnm install 20 if that's a concern?

I think you can implement it this way though with dedup_by_key? Sort order may matter as context:

// Now defaulting to descending:
// Descending order is necessary for selecting latest
value.sort_by_key(|v| std::cmp::Reverse(v.version));

// `--latest` Needs to be done after sort
// Then can flip sort order for ascending afterwards
if latest {
    // Technically should filter by major version
    // or if only for `--lts` by `LtsType::CodeName()`?
    value.dedup_by_key(|v| v.version);
}

// Presentational:
if let SortingMethod::Ascending = sort {
    value.reverse();
}

Technically that's only relevant for --lts (Some(None)), so if it needed to be optimized you could complicate it a little with two separate implementations.

Or I'm over thinking it :)

If it's not minimal to add, perhaps defer to a follow-up PR?

just see how stupid I am: I was saying that "I will accept a PR implementing this request", on a PR, that implements this feature. Sorry

The latest updates on your projects. Learn more about Vercel for Git ↗︎