It's an open source pub/sub and RPC server/client (similar to gRPC) - It has a client and server component written with JavaScript and Node.js.
I avoided using any dependency which relied on pre-built binaries. Also, I skim-read the code of all dependencies and made sure that they were well written and didn't use too many sub-dependencies.
The trick is to minimize the number of dependencies and maximize their quality.
I 100% believe that’s it’s possible to build a library without tons of bugs, and appreciate that there’s people who put out quality libraries like yours.
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.
It really depends on the size and complexity of the library. Do you think something like leftPad needed updates every month to perform its function as expected and remove bugs? Of course not, the mere suggestion is ridiculous, but also something like jQuery def needs constant upkeep. In the middle, there's a world of possibilities.
Leftpad shouldn't exist and any library using it as a direct dependency should be treated suspiciously.
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.
I strongly agree with this. Another set of libraries I take issues with is gulp and its plugins. I find that gulp plugins keep breaking constantly and are often flagged with vulnerabilities. The sad thing is that these plugins solve very simple problems, there is no reason for them to keep breaking every few months for the last 5 years or so.
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.
gulp itself is sort of abandonware and is dependent on libraries that have vulnerabilities (you judge yourself if they apply to you, if you run them on untrusted inputs etc). A remedy in my project was to rip it out altogether and replace it with shell commands.
Do you think something like leftPad needed updates every month to perform its function as expected and remove bugs?
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.
> "The author of leftpad could check its compatibility with each new version of Node that's released"
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?
This sounds feasible at all for you for all the millions libraries in npm not to be labelled as "obsolete"?
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.
