Alert: NPM modules hijacked
There&#x27;s a lesson to be drawn here about dependency hygiene. On one hand, code-reuse is a good thing, and incorporating other projects by reference is a way to make it happen. On the other hand, each dependency you add creates a little bit of risk: that the package will be updated in a way that breaks your application, or the package maintainer will go rogue, or the package will get hijacked.<p>Most programming-language communities manage the code-reuse&#x2F;dependency-hygiene tradeoff by concentrating code into a relatively small number of large libraries, and when people want a function or two that isn&#x27;t in one of the libraries they&#x27;re using, they incorporate it by copy-paste. In the Javascript&#x2F;NPM world, on the other hand, I see a lot of projects with dependency references to huge numbers of tiny dependencies.<p>Today, we&#x27;re seeing one of the reasons why that&#x27;s a liability. Most people will take away lessons about code signing and signatures, and presumably the NPM software is going to be improved in that regard. But the other lesson is that <i>projects should have fewer dependencies</i>. Using a library may be as simple as adding one line to a package configuration file, but using a library <i>properly</i> requires substantial due diligence on the library, its license, its bug tracker and its author.