I don’t know the details of your particular library but I think 50k/week downloads and no problems is an outlier. In my experience even projects with small audiences tend to accumulate outstanding bug reports faster than they’re fixed.
I do think as a general heuristic no updates for 3 months means it’s been at least 2 months since anyone paid attention to outstanding bugs, especially the npm ecosystem.
I'm not saying that because of the leftpad fiasco, I mean that any library that small should simply be pasted into your codebase because the risk of managing the dependency outweighs the benefits.
If I see a library which is supposed to solve a simple problem but it requires a large number of dependencies to do it, that's a big red flag which indicates to me that the developer who wrote it is not good enough to have their code included in my project - I don't care how popular that library is.
Node libraries are a bit odd in that respect because package JSON files have an "engines" property that informs users about the minimum and maximum Node version the library works with. The author of leftpad could check its compatibility with each new version of Node that's released, and update the engines value version accordingly. That would be quite helpful because abandoned libraries that aren't known to be working with newer Node versions don't get updated, and users can user that information to look for something else.
What that means is that any Node library that isn't being updated as often as Node itself is probably not actively maintained, or the author isn't making full use of Node's feature set.
Really? This sounds feasible at all for you for all the millions libraries in npm not to be labelled as "obsolete"? Checking if string concatenation still works on every major node release and tagging it as such?
Yes. I mean, they could just leave the max version of the engines property blank because it should always work if it's something as trivial as leftpad, but in a well-run package repository the work of checking library compatibility should be getting done. The fact that NPM is full of old libraries that haven't been tested in new versions of Node is a bad thing, and those libraries should be flagged as untested.
I think there’s a useful lesson there.
I check for things like over-engineering and I check out the author (check their other libraries if there are any).
SQLite seems to hit a good balance. There's always something new but nothing particularly breaking (from my light usage POV), so it looks live.
The author chimes in, says he’ll take a look next evening, then two years whoosh by.
There is an ambitious todo and nothing moves.
The code is in alpha for years, considered unstable, huge exclamation points in the readme that it should not be used, and yet somehow there are hundreds of reverse dependencies and it’s like this for years (usually should mean “RUN!!!”). Sometimes sneaky as it’s not a direct dependency for you, but for those two or three libraries used by like 80% of the ecosystem.
"Do one thing and do it well" - the unix philosophy, and why I still use cd, ls (dir on windows) today.
If a project exceeds two functions its probably doomed to become either redundant or broken.
If a project does one thing well, even if something else uses it, you can always decompose to it (your software is always useful, even when somebody writes the fancy bells and whistles version).