Before You Add Another npm Package, Ask Yourself These 5 Questions

Installing an npm package takes a few seconds. npm install some-package And that's exactly why it's so easy to overuse them. Need a date formatter? Install one. Need a UUID? Install one. Need to validate an email? Install one. Need to check if an array contains something? 😭 There's probably a package for that too. But every dependency you add becomes part of your project. So before running npm install , I started asking myself five questions. 1. Do I actually need a package? This is the first question. Sometimes the functionality you need is already available in JavaScript. For example, you don't need a package just to remove duplicates from an array: const unique = [...new Set(numbers)]; Or to check whether an array contains a value: numbers.includes(10); The point isn't: "Never use packages." The point is: Don't add a dependency just because it saves you three lines of code. If a package solves a genuinely complex problem, absolutely use it. 2. Is the package actively maintained? Before installing something, check its repository. Look at: - Last release - Open issues - Pull requests - Recent commits - Number of maintainers - Documentation - Compatibility with your version of Node.js A package with millions of downloads isn't automatically a good package. What matters is whether the project is healthy enough for your use case. 3. How many dependencies does it bring with it? You install one package: npm install package-a But that package might depend on dozens of other packages. Your dependency tree can quickly become: your-app └── package-a ├── package-b │ ├── package-c │ └── package-d ├── package-e └── package-f You're not only trusting package-a . You're also trusting the ecosystem underneath it. You can inspect your dependency tree with: npm ls 4. What does this dependency cost my project? "Cost" doesn't only mean money. A dependency can cost you: - Bundle size - especially important for frontend applications. - Performance - some libraries do far more work than you actually need. - Security - every dependency is another piece of third-party code. - Maintenance - packages can become deprecated or abandoned. - Complexity - a tiny utility shouldn't require an entire library. Instead of asking: "Does this package work?" Ask: "Is this package worth having in my project?" 5. Can I remove it later? This is probably the question developers ask the least. Imagine your project has 80 dependencies. Then one day you realize that five of them are only being used for tiny utility functions. Removing them can become surprisingly difficult because you have to figure out: - Where they're used - Whether they're used indirectly - What breaks after removal - Whether another package depends on them - Whether the replacement changes behavior A dependency is easiest to remove when you never needed it in the first place. A Simple Rule I Follow Before installing a package, I try this: Can JavaScript already do this? ↓ YES → Use native JavaScript ↓ NO ↓ Is the problem complex enough to justify a dependency? ↓ YES ↓ Is the package maintained and trustworthy? ↓ YES ↓ Check size + dependencies + license ↓ Install This doesn't mean you should reinvent everything. If you're building authentication, payments, database access, validation, image processing, or other complex functionality, established libraries can save enormous amounts of time. The goal is simply to make dependencies intentional. The npm install Reflex One thing I've noticed while building projects is how easy it is to develop an npm install reflex. You encounter a problem. You search Google. You find a package. You install it. Problem solved. But sometimes the better engineering decision is to stop for 30 seconds and ask: "Do I really want this dependency in my project?" That 30-second decision can save you hours of maintenance later. Final Thought Dependencies are not bad. Unnecessary dependencies are. Use packages when they provide real value. But don't turn every small problem into another entry in package.json . Your future self - the one debugging the project six months from now - will probably thank you. 😭 What's one npm package you can't live without? Drop it in the comments. I'm curious what everyone is using. 👇 Top comments (0)