26 Nov 2018 - by 'Maurits van der Schee'
People are angry at the author of the dependency:
You put at risk millions of people, and making something for free, but public, means you are responsible for the package.
There is a huge difference between not maintaining a repo/package, vs giving it away to a hacker (which actually takes more effort than doing nothing)
And full of good advice for the readers of the issue:
maintainers should start using static dependencies and update dependencies only after code reviews.
If you want security maybe move away from node.
But they seem not to address the real issue: the hidden costs of dependencies.
The developer community seems to agree that it is bad to "reinvent the wheel" and that suffering from "not-invented-here" syndrome is bad. Unfortunately they forgot to warn us for the "hidden costs of dependencies".
I'll give some examples of these below.
Dependencies may have bugs that are not fixed in a timely manner. They could also be pulled offline for legal reasons. Sometimes we see forks appear to guarantee availability, but these new dependencies have an even bigger concern for security and compatibility.
Who wrote the code? Does the author publish a real name and contact details? I think successful (well-known) developers (especially at larger corporations) are less likely to sell out as they have a reputation to protect and most likely no need for making a quick buck.
Will the API use semantic versioning and stay stable? Will the dependency not drop support for certain browsers or operating systems? How about the licenses of the chosen (transitive) dependencies, will these be compatible with yours, now and in the future?
PS: Liked this article? Please share it on Facebook, Twitter or LinkedIn.