Comment by chipotle_coyote
11 years ago
I think the article's thesis is essentially that every dependency your project pulls in -- which includes all the dependencies your dependencies pull in -- is a point of potential failure. I understand the "don't re-invent the wheel" defense, but the Node/JavaScript ecosystem tacitly encourages its users to build vehicles by chaining together dozens of pre-made wheels, all of which depend on more wheels, and each and every one of those wheels has a small but non-zero chance of exploding the next time you type "npm update."
(And, y'know, maybe it's because I'm not a JS programmer, but the notion of looking for a module to implement a string padding function would never have even occurred to me.)
Worse yet, a backdoor or legitimate bug in any of these module could leave huge exploits in the entire Node.js ecosystem.
A backdoor or legitimate bug in any line of custom code could leave huge exploits in your system. A widely-used published module is likely to be much more reliable, at least on average.
Except when you are using a library like boost or pandas you know the people behind it know what they are doing. When you are importing from a thousand different package authors any one of those people could be incompetent and/or malicious and screw up your entire code base.
Worse yet, the OS is compromised. This is why I hand roll all my encryption libraries. /s
Riiiight. Because cryptography is identical to an 12-line string padding function.
3 replies →
The problem is not that, the problem is depending on unreleased versions, instead of simply depending on the version that was written when u wrote your code.
a Git submodule like approach would be much better