-
Notifications
You must be signed in to change notification settings - Fork 467
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add filtering options to ls-remote
#1063
Conversation
🦋 Changeset detectedLatest commit: a436254 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 # 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 |
@Schniz I've refactored it to take |
@polarathene I've added support for filtering LTSes with Edit: Your example picks out the latest versions from each LTS, should I make that the behavior here as well? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not too familiar with the project but hopefully the review helps :)
src/commands/ls_remote.rs
Outdated
/// Only show latest LTS versions | ||
#[arg(long)] | ||
lts: Option<Option<String>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it need to be two layers of Option
here?
EDIT: Yes, technically since it appears to be relying on:
None
forfalse
(no option / flag provided)- Inner
None
fortrue
(aka--lts
), no value provided Some(Some(String))
to represent a version codename to filter against (eg:--lts iron
).
It can technically be worked around with a variable arg number, or using an enum similar to LtsStatus
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the related functionality with retain()
I didn't see something that indicated it also filters to "latest LTS versions", is that doc comment accurate? If so a bit more context for the relevant logic in the apply()
method might be worthwhile?
EDIT: Or was it meant to be only the current LTS release series as default for --lts
, rather than all LTS series?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can take a look at my pr #944
That is what I suggested 😝
My last review provides a checklist with two items referring to your PR as good additions (docs + tests).
"fnm": minor | ||
--- | ||
|
||
feat: add remote version sorting and filtering |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not too familiar with how this changelog entry is handled, but might be relevant to include the actual flags / examples here to appear in the release notes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure either, seems like this was added fairly recently
That's great, thanks! ❤️
That might be nice to have too. I suppose it should be an additional flag like 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 $ 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 I think you can implement it this way though with // 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 Or I'm over thinking it :) If it's not minimal to add, perhaps defer to a follow-up PR? |
ls-remote
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Use
truncate()
for--latest
. - Update the project docs file (like was done here).
- @Schniz may chime in if they want the new options included in the changeset file too 🤷♂️ (your PR description listing each addition seems like good content for that 👍 )
- Optional: Better clarify
--lts
help text (some possible choices suggested). - Optional: Consider adding some tests (like was done here).
After that should be good for @Schniz to handle final review 🎉
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 |
Co-authored-by: Brennan Kinney <5098581+polarathene@users.noreply.github.com>
Co-authored-by: Brennan Kinney <5098581+polarathene@users.noreply.github.com>
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
This PR adds the following options to
fnm ls-remote
:--lts
: only show LTS versions--lts <name>
: only show LTS versions for a specific codename--sort <asc|desc>
: sort versions by ascending or descending--filter
: filter versions by specifying aUserVersion
--latest
: only show the latest version matching all of the criteria above