Search: Add preview of package stage

[mk-pmb]

Hi! As mentioned on the policies repo, one of my problems with placeholder packages is that they clutter my npm search results, and (thanks for fixing this first aspect!)
annoy me because it takes too many clicks and seconds of loading time just to figure out that the package really had no substantial content.

To help me determine some obvious, machine-detectable signs of placeholderism, I'd like the search results page to inform me, near the package name, about:

• Does this package include a readme file that npm could show me if I decided to open the package details page?
• Does the package contain any file that could usually warrant a download, i.e.
  • is a file
  • contains any non-whitespace character (or if npm cannot decode it to Unicode: any byte that, in ASCII, would be not whitespace)
  • is not already displayed on the package details page (e.g. the readme)
  • is not config or meta of a commonly used version control, package manager, or similar dev tooling (e.g. .gitignore, .gitconfig, .npmignore, package.json, bower.json, .bowerrc, .eslintrc, travis.yml, …)
  • the first word of its file name is not a usual policy file name like "CONTRIBUTING", "LICENSE", "COPYING", …
• … or if only such files, are some of them declared, via package.json, to be meant as actual package content? (As a third, distinct state of the previous flag.)
  • aka, is this package purpose to distribute your example bower manifest files, or are they just meta-data for *.js files that you plan to release in a next version of the package?
  • We might need to invent a new package.json field for that.

This is not an attempt to judge the usefulness of a package. If you're a ninja kid trying to "game the system", then yes, your README.md file that contains just "hello world" will be enough that you have "cheated" this placeholder detection and "tricked" me into reading the details page, and your foobar.txt that has just "If you read this you wasted your time" in it might be able to "trick" me into downloading your package, reading that and feel totally, deeply, personally PWNED for all eternity. That's ok. Your effort shall be rewarded.

I don't ask for a perfect summary system, I just want npm to help me save effort in the most obvious cases that might very well be accidential uploads.

[Polarisation]

Options to filter the search results by these criteria would also be helpful. So for example if I could hide from results any packages that do not have a readme or do not have any code.

[mk-pmb]

In that case, there should be a hint at the top how many packages have been hidden by the filter, in order to remind people that a package name not showing up doesn't mean it's unregistered. The amount can be an estimate like "5+" or even "some".

[rockbot]

hi @mk-pmb - we're in the process of reworking our search pages and will take your suggestions into consideration. thanks! 😄

[aredridel]

How do the new search filters feel? Are things more relevant now?

[mk-pmb]

Are things more relevant now?

I haven't experienced major incidents of totally unrelevant packages since the time those "search by" criteria appeared. I tested a bit further: The new search ranking seems to help if there are lots of packages for my topic, and no placeholder package squats the exact keywords I used. I'm optimistic that this turns out to solve my clutter problem, so I crossed that out in my opening post.

However, when I repeat some of the searches that annoyed me last year, I still can't see any hints that help me avoid clicks that will turn out to be useless. Testing other new keywords, it seems this problem appears when a placeholder does use my keywords in its name, or there are few related packages overall.

The core idea of my feature request, giving users visible indicators about some maturity-linked aspects of the package, seems to not be implemented yet, and I still consider it useful.