The recent series of attacks on npm packages has significantly impacted the community, making us question the security of the libraries we use, whether in development or production environments.
From the very first day I learned about Node.js, npmjs... I noticed that every time I ran npm install, a node_modules folder and a package-lock.json file would appear. Out of curiosity, I opened them andโoh my!โwhy are there so many folders in there, while the package.json file shows that I only installed the express library? ๐ค This means that installing express automatically installs a bunch of other packages. In other words, express depends on other packages, which in turn depend on even more packages, leading to a "dependency hell." This explains why installing just one library brings in dozens of libraries you've probably never even heard of.
What's quite interesting is that if you investigate any given library and trace the dependencies it relies on, and then those dependencies' dependencies, you'll eventually come across a ridiculously tiny library that seems... absurd. It performs a single, extremely simple task, something that could easily be handled with just one JavaScript function. Yet, this "absurd" library has millions or even tens of millions of weekly downloads. Why is that?
It's all due to technical debt from the past. JavaScript lacked a standard library to handle what seemed like basic tasks, so the community created their own solutions. Over time, these packages started being used in other packages at breakneck speed. Imagine them as bricks used to build a house, where newer bricks are stacked on top of older ones to create a sturdy wall. If you break one of the original bricks, there's a high chance the whole wall will collapse. This reminds us of the events that have occurred recently. So why not try to fix it?
It's hard! Although JavaScript continuously introduces newer, more powerful specifications, the house is already built, and the wall is already sturdy. Now, even if you introduce bricks that are 100 times stronger than the old ones, what's the point when the house is already completed? Tear it down and rebuild?
Still difficult, because it's so deeply ingrained in habits that it's almost impossible to turn back. Nevertheless, part of the community is striving to change this. I know of some repositories similar to npmjs that bring a new design philosophy aimed at reducing dependencies and leveraging the standard library. Examples include jsr.io. Take a look, and you'll see that they almost have no dependencies on other packages. This reduces complexity, mitigates attack risks, and avoids dependency hell.
Anyway! Talking too much without solving anything. I'm just pointing out what I know about packages on npmjs. In truth, people have already talked a lot about this issue. Everyone has their own perspective, so I'm just adding a bit more to enrich the conversation ๐ค