# The excess of libraries and obese projects: a bad and insecure development practice

Published: Apr 19, 2026

URL: https://crony.cl/logs/el-exceso-de-dependencias-y-proyectos-obesos-una-mala-e-insegura-practica-de-desarrollo

---

As developers, we sometimes run into a problem and spot a library that solves everything with one click. The speed at which you can just run npm install and keep coding is real and sounds wonderful, but if we do this over and over again, our project starts getting bloated and it becomes very easy to lose control and understanding of what we actually have.

What today is a shortcut that saves you time, tomorrow can be a dead end. To be clear: using libraries obviously works, but like almost everything in life, the trick is balance.

Think of Occam when you look at your package.json

In the 14th century there was a philosopher named William of Ockham, who inspired a principle widely known today as Occam's Razor. While the exact phrase "Entities must not be multiplied beyond necessity" was actually coined centuries later, Ockham's original writings stated something very similar: "Plurality must never be posited without necessity." Over time this concept evolved, and today we know it as "Among several possible explanations, the simplest one is usually the correct one.

Applied to code, that idea is just as powerful: if you can solve a problem with fewer pieces, solve it with fewer pieces. Don't install a library when a native JavaScript function solves the same problem. Don't add a dependency when 10 lines of your own code are enough. The simplest solution is not only more elegant, it's more secure, more maintainable, and more yours.

Every new dependency you install is like a small recurring expense that, if left unchecked, can grow into an enormous debt that ultimately crushes you. Here are some real risks you could run into if you don't keep them under control:

Libraries that turn into ghosts

Imagine your main feature depends on a library and, out of nowhere, its creators disappear, abandon the project and never update it again, leaving you with old, unsupported code full of potential bugs. Pretty unsafe, don't you think?

Backdoors and irregularities 
Now think of every library you install as a new door in your house. Sure, most of them are safe, but we're seeing more and more news about libraries hiding malware, like the 2 malicious versions of Axios in early April '26. That's why, when your terminal tells you something about vulnerabilities, it's always better to listen. npm audit is not a suggestion, it's your alarm system, and ignoring it is like leaving your front door wide open.

Horror updates 
If you use React or Angular, for example, and you got used to installing a ton of libraries for everything, then every time you update your framework you'll kick off the game of "will everything still be compatible?", possibly spending hours fixing things that worked perfectly before. And while it's true that incompatibility issues can happen with any language update, the risk here is the number: more unnecessary libraries = more time spent trying to fix incompatibilities.

The stowaways, freeloaders, or "friends of my friends" 
When you install a package, you have to know it doesn't come alone. A project with 15 libraries can have HUNDREDS of hidden packages. This makes your app heavier, slower, and with far more blind spots where a real risk could be hiding.

To better illustrate this point, let me go back to the malicious Axios example (March '26), where the attackers didn't put the malware in the library's source code, they were smarter: they used what's known as a "Phantom Dependency", modifying the package.json to include a small library called plain-crypto.js, whose sole purpose was to run a post-install hook (meaning: execute scripts right after npm install) and download a Remote Access Trojan (RAT) to steal credentials, API keys, tokens, and passwords in general. This is a very real and increasingly common risk, so you need to be careful about what you install and how you install it.

That's why, if you develop in JavaScript, I suggest you replace npm install with npm install --ignore-scripts. That flag prevents exactly the attack vector used here: it stops automatic post-install scripts from running, which is precisely how the RAT got in. This is also recommended by OWASP in its official guide.

How can you build better habits and code with good practices?

Don't panic, not everything is lost, and it's not like I'm about to recommend you code every last div from scratch, it's just about being smarter.

Before even thinking about installing something, try to remember or look up what the language already gives you:

Typical library

Native alternative

axios

fetch() (modern Web API)

lodash for _.cloneDeep

structuredClone() (native since 2022)

moment.js

Intl.DateTimeFormat or the Temporal API

uuid

crypto.randomUUID() (native in modern browsers and Node 14.17+)

is-odd / is-even

n % 2 !== 0 it's just a single line of code

And apply the same logic to external CDNs:

Typical approach

Alternative

Google Fonts

Host the font locally. Serving the one font you actually need from your own build eliminates an external dependency and reduces latency for the user. 

Ask yourself: do I really need to load the entire Google Fonts catalog? Or is it enough to download the one font I use and make it part of my build?

It's not about never using libraries. It's about asking yourself first whether the language already solves it for you.

So, how do I minimize the risk?

Get into the habit of running npm audit and make it part of your routine.

Ask yourself:

does the framework I'm already using solve this?

Is it worth adding this technical debt and its transitive dependencies to my project?

Every so often, do a cleanup of your package.json. Tools like depcheck can help you see which libraries are just sitting there collecting dust.

If you truly need to install something, do a little research first: does this library have an active community? Is it deprecated? When was the last time it was updated? A quick look at its GitHub can save you a serious headache down the road.

→ If the answers don't leave you feeling confident, remember Occam and go with the simplest solution.

Libraries are not the enemy. Not thinking is. It's your code, your decisions, your responsibility. Build software you're proud of today, and especially tomorrow.