SearchOrder as part of the API (no impl yet)

[isoos]

No description provided.

[mkustermann]

May I ask what we are going to use this for? We have only one search box. Do we want to let the user choose (via some drop-down menu) how to rank? I would assume we just need to tweak the way we combine the different metrics in order to get good results.

[isoos]

May I ask what we are going to use this for?

Immediately: I want to replace PackageVersion.detectedTypes (which is flutter-only) with pana-recognized platforms. E.g. /flutter/packages will query search with platforms=flutter (maybe turn of the rest, so that only flutter packages are shown), and it needs to order them in reverse chronological update time (SearchOrder.updated here).

Short term: Query the most popular packages (optional: group by platform), to be displayed on the site's index page.

After that: It kind of enables a search-box like the top-left side of https://www.npmjs.com/search?q=
Whether we want to do something like that is up for debate and UX is to be figured out, but at that point it is just a quick add-on.

I would assume we just need to tweak the way we combine the different metrics in order to get good results.

I believe that is correct, I don't imagine too much work needed to implement it. We will still need the API part for it though...

[mkustermann]

Thanks for the explanation, sounds reasonable.

just a few minor comments.

[mkustermann]

Why not just change {SearchOrder orElse()} to {SearchOrder defaultsTo}? Then call sites don't need to allocate a closure but can just provide a constant.

[mkustermann]

defaultsTo: SearchOrder.overall

[mkustermann]

If you write a test, then you might as well add a case for parseSearchOrder('foobar', defaultsTo: ...) :)

[isoos]

added

[mkustermann]

What's the difference between health and maintenance? For me, not knowing what it means, I would assume it's the same as health.

[isoos]

• health: How the code qualifies against our tests (e.g. strong mode, some linter rules, works with the tools, doesn't have too many warnings)? E.g. I can have a lot of code in it that is using a deprecated API and it will likely break -> bad health.

• maintenance: How frequently is the package updated with new versions? E.g. If I publish a new version every 2-3 months, that seems like a steady maintenance. If I publish a new version after 2 years of break, that should score lower, even though it may be fresh. (There is a fundamental difference here with updated, which only cares about the latest publish time.)

[mkustermann]

Yeah but you can interpret update frequency in different ways: Frequent updates (might indicate active maintenance, or unstable package) or very rarely (might indicate stable package, or unmaintained package)!

[isoos]

Good point. I'll remove it for now, it should be cheap to re-introduce it later.