Do You Really Need That Package?
A pragmatic approach to managing dependencies
In the shadow of the npm supply chain attack, it got me thinking about the security of packages and dependencies.
On 8. of September, 2025, a supply-chain attack compromised 18 popular npm packages. Together those packages receive billions downloads each week, making this one of the largest npm incidents in recent years. It is enough to trick one maintainer to compromise a package and affect thousands of projects. Luckily, the packages were quickly fixed and the issue was mitigated.
Many developers are adding dependencies without much thought, and some improvements could be made.
How much do you trust your dependencies? Do you trust a random developer on the internet? Because if you add any package to the project, you are basically trusting that developer.
Yes, packages can resolve many issues and save time, but they can also introduce more liability.
I was at the same place a few years ago, adding dependencies without much thought. However, as I worked on more and more projects, I began to realize that adding dependencies is not without cost.
Each dependency can introduce:
- issues and bugs
- security vulnerabilities
- maintenance overhead - you need to keep them updated
- complexity to the project than necessary
There are many cases where you should actually add a dependency, for example:
- you use a specific SDK from other company
- you need to add database or HTTP client
- any complex functionality that would be hard to implement on your own to get it right
It does not mean, everyone should develop their own database or HTTP client.
These problems are hard to resolve, and a package should be used. For these, there are many great packages in any ecosystem, usually.
Safety tips for package management
- remove autoupdate in your package manager and pin the used version - so you do not automatically get new versions
- if you want to update the library check at least the changelog, code, and ideally test it locally before updating
- if the package is not maintained anymore and requires updates, consider moving on to another package
How I think about dependencies
All these tips are useful and may sound paranoid, but I prefer a totally different mindset:
How not to add dependency, instead of how to add dependency.
The majority of packages are not necessary and can be implemented on your own with a few lines of code.
Developers just do not like to implement little things on their own, as it is boring and annoying to them. They would rather slap the dependency, import it, use one fancy line of code and move on.
Do you like some UI visual component in some package? Check the GitHub repository of the package and inspire yourself to implement it on your own. You will learn a lot, and you will have full control over the code.
I think this is the most common misconception to use UI packages for any tricky UI component or some fancy one-liner, but, checking the code of these packages, they are often implemented with a few lines of code.
Here you have a couple of ways to avoid the actual package:
- you can copy it to your project (with license added, of course)
- you can take inspiration from the code and implement it on your own
- the new one is here: you can ask AI to implement it for you - it is often faster than copy-pasting from the package
AI is actually great at writing annoying boilerplate code that you do not want to write on your own. If you need to implement some parsing, data transformations, checkers, etc., just ask AI to do it for you.
If you are junior dev, do not use AI and try to learn the code on your own.
Use whatever assistant you like, but be careful and check the code it generates. All generated code can still contain bugs or security vulnerabilities. Generate it, review it, refine it and then use it.
If you connect the dots correctly, you can avoid adding many dependencies to your project and still be productive.
In other words, any package containing less than 100 lines of code, or one file with implementation, you can probably implement on your own. Do not be lazy, be better than that.
Conclusion
Dependencies are a double-edged sword. They can save you time, but they can also introduce more issues and liabilities to your project.
In prototypes, MVPs or throwaway projects, you can add whatever you want, but in production code, you should be more careful and consider if you really need the dependency or if you can implement it on your own.
Socials
Thanks for reading this article!
For more content like this, follow me here or on X or LinkedIn.
