It's on a list :-)

Maybe I could make it less aggressive: mark it if it was inactive for 1 year (INACTIVE) move down if it was inactive for 2 years (ABANDONED) What do you think? This is obviously very subjective so I'm really curious about other opinions.

Yeah, doing npm audit is probably great idea, and it shouldnt be too hard. What do you mean by extracting urls from source?

Thanks for your feedback, really. You're right it still has some issues but latest release of cheerio was more than year ago. It's obviously not a dead project but it's not very active either - healthy projects usually have at least few releases during the year. Inactive projects are simply moved down (but before new projects). SearchLibs doesn't do any relevance searching (it could but I think it's too much magic), you only get what you ask for, which is sometimes good (search rest api ) and sometimes not ( rest framework ). I think if there were term suggestions it could resolve this issue but again, I'm open to anyone opinions. You've also mentioned DefinitelyTyped - I'm actually thinking about being able to leave these results out (with UI). In the meantime you can exclude anything with -keyword syntax. And lastly, favoring exact results sounds good (npm/yarn do it) but if you search for date you get package date , with 10 stars and latest release 7 years ago BTW: for some reason, yarn thinks this package is 1 year old but no, it's really 7 years.

I made an alternative search engine few months ago... Basically I was not satisfied with npms.io so I've tried to come up with tool which matches my process of selection as much as possible: github stars activity, age releases, deps, issues grow (how much is it getting popular) And most importantly I wanted to be able to "filter out" what I don't care - so for example if I'm searching for charts, there is a lot of "noise" with vx packages, I can easily search for "chart -vx" and you use parentheses and | The link is searchlibs.com I keep it updating every 2 weeks and I also have a lot of new ideas so if you're interested, feel free to bookmark it and stay tuned :)

Stack is freed automatically at the end of call unlike heap which has to be garbage collected, which in turn can (and will if we're talking about long-running node.js app) cause "stop-the-world" problem