identify/label library forks and score/sort them accordingly

[panva]

It is not uncommon for libs to forked and then republished to the registry, when this happens for an unmaintained parent, cool. But more often than not these forks get abandoned and then still show up in the search results above the original (now already updated and even continuously maintained) library.

Example: https://www.npmjs.com/search?q=oidc+provider

The top search result is a fork, one that serves a single company's core case, no one should be using it because it ties in internals of that company and in some cases strays away from the standards oidc-provider implements.

8 of the front search result page are forks with mostly all of them not even bothering to change the tags, the homepage or repository package.json fields.

I think it would be fair if, similar to github, the fact that these are forks would be clearly signalled. Results could get aggregated so that a maintained fork shows up on top.

[MylesBorins]

@panva how are you imagining we would identify that a package is indeed a fork? For GitHub we have that symantic data, in that there was a physical action to fork the repo. If someone simply clones and re-pushes the code then we have no identification that the repo is in fact a fork.

I'm trying to think through how we could surface this information without potentially causing false positives.

[panva]

how are you imagining we would identify that a package is indeed a fork?

I recognize this is challenging. But in more cases than not this is as simple as identifying that the package has not changed the package.json fields, didn't bother to change its readme (compare shas?), etc.

Maybe it'd be worth taking a step back and before discussing this as a solution look at the root of the issue - subpar search results, and figure out how to improve those.

I think forks shouldn't be ranked over a maintained original module. Serving the legit maintained result over forks is what most users expect. These forks definitely do have a place in the registry but they're usually discovered by searching the repository issue trackers for a particular fix to an issue, not searching npm, because the only thing that usually differs from the public package.json surface is the package name.

Or do you imagine someone searching for "oidc provider" in npm looks for the many forks? unlikely. And yet one of those forks is ranked as more relevant.

[panva]

#84 does actually seem relevant to this discussion.

[MylesBorins]

I don't think there is anything actionable for now on this.