Should not put exact matches first

[sindresorhus]

I don't care if a module matches what I wrote. I want the best one.

For example, https://npms.io/search?term=electron 99% of people would want the second result electron-prebuilt, not an obscure and unmaintained CLI framework with much lower score.

[pedro93]

This may be your own opinion but not the usual use case. If people type a module name, they expect to get a link to it as the first result.

Read #48 for more information.

[atduarte]

@sindresorhus given that autosuggest and the package's page don't yet exist, finding a specific module, that's really bad, would be near impossible.

As I see it, npms isn't just about discovering. I use npms as a easy way to find the documentation I'm using and so when I write a name I want that exact package.

Nonetheless, I agree that in that case and others, it may lead to some misguidance. Maybe we could distinguish the bad package to indicate that it just shows up because of the exact name match.

[sindresorhus]

Read #48 for more information.

Looks like those are just cases of the metric analysis being off, not for artificially placing exact matches at the top. I agree mithril should be before any mithril plugins, but that should be fixed in the analyzer. Doing it this way is just covering up holes in the metric analysis.

finding a specific module, that's really bad, would be near impossible.

So your argument is not being able to find a really bad module. 😲

I use npms as a easy way to find the documentation I'm using and so when I write a name I want that exact package.

You go to npms.io, write package name, press enter, click package name, instead of just: $ npm docs package-name. I think you should revisit whether your personal use-case is worth making the search results bad.

[jamestalmage]

I use npms.io for much the same reason as @atduarte when I am on mobile.

Maybe https://npms.io/docs/package-name should just redirect right to the appropriate repo?

[vadimdemedes]

I agree with @sindresorhus, chances are I'm looking for a popular/quality module, rather than the exact match. Perhaps you could check the "difference" between popularity (stars/forks/deps) between two matching modules and order by that? I think it'd solve cases like this one.

[pedro93]

@sindresorhus you have said that, exact word matching as the first result is wrong but in the case of the mithril package it's fine. How then would you suggest changing the npms ecosystem to handle both cases AND the use-case that @atduarte and @jamestalmage have?

[jamestalmage]

My use case would be pretty easily resolved with the redirect url I just mentioned, I think @atduarte's would too.

chances are I'm looking for a popular/quality module, rather than the exact match

Having a poor first result is annoying, but it is not as annoying as not being able to find your module when you type in the name exactly. Without elevating exact matches debug might not even appear on the first page. I have been using npms.io since before #48 landed, and I had numerous WTF moments where I couldn't find what I wanted, and #48 seems to have solved many of them.

So your argument is not being able to find a really bad module

Let's be honest. npms.io has not yet matured to the point where "poorly rated" equals "really bad" yet. debug is a good example, and one I found very easily, there are others I'm sure. I am certainly hoping the algorithm evolves to the point where we can safely remove the "exact match" boost, but it's definitely not there yet.

Maybe we could distinguish the bad package to indicate that it just shows up because of the exact name match

I think that sounds like a reasonable solution. I make it smaller somehow: Remove all but the first line of the listing? Slightly smaller font? Maybe just a simple one line sentence in a small italicized font near the top of the listing:

debug matches your search terms exactly but is poorly rated - is that what you wanted?

@satazor, @atduarte - Are you logging what people actually click and comparing it to your top rated result?

[satazor]

I'm writing this on my phone because my laptop is being repaired, so I will be short. I will elaborate a more comprehensive reply once it is repaired.

Mithril has a bad quality and maintenance score because the actual issues and other stuff we use to measure is on a different repository than the one written in the package.json (which they call development repository).

I don't know why they do this, branches could have been used instead. I don't know if we need to handle this case in the analyzer.. I would prefer not to add complexity the code to solve edge cases.

[Qix-]

Why not allow the selection of how you want results handed to you? Kind of weird to not be able to order-by any of the metrics.

• Best match gives you the most lexically similar package
• Best Score weights the modules by their score
• Popular weights the modules by their popularity
  
  etc.

I think it's funny we're debating which should be shown when obviously it's a subjective matter and can even change from search to search. Literally everything else on the web has a way to order by something.

[kevva]

Having given up on searching at npmjs.com in favour of googling <packag name> npm or using npmsearch.com I'm all for sorting by popularity/relevance rather than an exact match. And chances are, if you're searching for documentation, you're most likely using a more popular module rather that the one you're search matches exactly.

If I wanted an exact match I'd just go to npmjs.com/<package name>.

[sindresorhus]

@Qix- You can't compare it to Ebay. They serve a completely different market and needs. Google doesn't have sorting choices. The Verbatim option is because Google likes to auto-correct (badly). That does not apply here. I don't think it's worth sacrificing simplicity for some options with limited and hard to understand difference (first two options). I would honestly rather have the current exact matching than adding options. Adding options is usually the lazy way out. I believe the current search is a combination of Best match and Best score, which in most cases works great. Popular is rarely a good metric alone.

[atduarte]

I'm noticing some mix opinions about this. I think we can make it work for both.

The API search endpoint would just return the list of packages ordered as they should, according to score and relevance. A list of packages that match exactly the name, separately.

On the web UI, these packages could show up on the right or, like @jamestalmage suggested, on the top of the list but with a different, much smaller size.

This solution would allow to keep the results list as it should, with the best packages first. While allowing people looking for a specific "unknown" package to find it, without having to know the package's page address.

I'm just not so sure about how it could work on apps such as npm-search or on integrations such as this: https://github.com/boneskull/alfred-npms.

[SamVerschueren]

I'm with @sindresorhus on this one. In case of other packages like gulp for instance, gulp really is the first result because it has the highest score. So it looks like the score is calculated correctly because in case of electron, the electron-prebuilt has a much higher score which is 👍 .

[satazor]

For the record this happened today: https://twitter.com/fishrock123/status/748159392793694209

[SamVerschueren]

At npms.io, semver has the highest score and will be the top result.

[satazor]

After thinking a lot about this, it's better to keep it this way since most people agree this is the right way to do it. They actually complain about npmjs exactly because of this. Still, we should improve the UI and highlight the exact-match differently in case it's not the best module. We need to come up with a good way to do this.

[satazor]

npms-io/npms-www#97