As developers, we don’t invest enough effort when we choose a javascript npm package.

The naive process of installing a npm package goes like this:

1. I have a problem to solve;
2. I look into the specifications, algorithms to solve the problem;
3. I find a npm package that helps me solve the problem and complements my algorithm; (e.g. I may need is-odd module; joking)
4. I finish the functionality and call it a day – I totally deserve a and now I get to explain to my girlfriend why that makes me a superhero!

This was me as well in the past (apart from the superhero part – I am still a superhero).

The above approach is wrong and you will understand the reasoning below. There are some crucial aspects you have to consider when installing any npm package.

This is something I wish I knew when I was younger. Stay with me in this article to find out what you’re doing wrong when it comes to choosing a npm package.

Before getting into what to look for when choosing to install any javascript node module, we have to understand what are the risks we are exposing ourselves to.

Consequences of wrongfully choosing an npm package:

• Open Source Licensing
• Maintainability
• Security
• Package Size & Dependencies
• Node Module Size & Dependencies

---

This is what I love to do – I am also on Twitter, Instagram, Linkedin and here – writing about any kinds of interesting subjects in the web & mobile development world. Don’t get discouraged by the low number of followers and join me in this amazing journey. Thank you.

Enough playing, let’s get back to work now…

---

1. Open Source License

(e.g. Apache License 2.0, MIT, BSD 3-Clause, BSD 2-Clause, GNU General Public License (GPL), GNU Library or “Lesser” General Public License (LGPL) to name a few)

Who cares about licensing, right? We just need to solve our problem, don’t bother me with lawyers “” details! Well, it’s not really like that.

Open source does not mean that anyone can use any library in any way they want.

You might create a product for your startup and look for investments. When investors get interested enough in your product, they will have a technical and financial due diligence team assessing your application.

All open source projects have a usage license attached to them. Some might even say something along the lines: “If you use this module inside your application, I have the right to ask you for your application code source at any point in time while using it” – or they might say that they own the IP (Intellectual Property) in your product functionalities that are using that module (crazy, rare, but not impossible). Don’t ever underestimate your application IP, it’s a deal breaker for investors.

How to prevent this:

• Make sure you read carefully what the authors allow you to do and what your rights are when using the piece of software. There are libraries that you cannot use in a SASS application, for example, unless you pay (even though they are open source and the code is public).
• Make sure that the license does not force you to share any code or have any IP power over your application or functionalities using that library;
• Make sure the license is free to use, otherwise purchase the right of using the license for your application;
• Generally, one of the licenses that I am most comfortable with is MIT license or a similar one; depending on the problem I am trying to solve

2. Maintainability

I cannot stress enough how important this is, especially for startups, small-to-medium companies (enterprise level companies can afford to either have a team maintaining the node module or sponsor the continuation of module development & update);

I am referring to modules that are left to die due to the creator and the community abandoning the project. With each update the module in question becomes a security risk for the whole application or service.

If you already have a module that is not maintained anymore, it’s time to evaluate the refactoring costs (using another module up to date) VS maintaining the library in house in the future. Make this evaluation as soon as possible, don’t blindly build new functionality over it (with each new functionality the complexity grows and so does the cost in the future).

How to Prevent This:

• Regular updates: first thing to do when looking into a module, even before evaluating it as an option, is to look at the last release date. If you see it was released months or even years ago, search for an alternative and don’t waste time evaluating it, no matter if it solves your problem! It can become such a pain in the future that it’s not worth it.

• Companies behind the module (e.g. angular which is developed by Google, reactjs developed by Facebook – sorry, I meant Meta);
• Module Sponsors;
• Contributors & Community – look for modules with a big community, large list of contributors. Also pay attention to the number of github forks, stars and upvotes;
• Make sure to look over deprecated code, outdated dependencies or overall old code (e.g. if you are looking to install a module for your react application, see what react version it is using);
• Incompatibility with current framework / technology stack in any way;
• Slow updates reaction
  • Being exposed to security flaws (updates should happen right away)
  • Extensive list of unsolved issues, slow reaction to solving them, contributors not engaged

In Github.com you have an Issues tab where people using the module add comments. Check that, see how many issues people posted, how recent they are and notice the contributors’ engagement into issues fixing.

• Contributors’ vision for the module (e.g. nextjs has a vision and a mission, it’s not a simple random node module package to solve a single problem)
• Great products/services that derive from that module (e.g. maintaining the module is profitable for those products/services meaning there will be a high chance of long term maintainability) (e.g. nextjs is owned by Vercel which offer services for hosting nextjs apps – it’s kind of a silly example due to the vast adoption but still a valid argument)
• Mass adoption (e.g. nextjs is one of the most used reactjs frameworks; e.g. reactjs itself)

3. Code Quality

If the community of the module is big, there’s a slim chance for the code quality to suck. However, if you find a module created by some dude with less than 50 stars, make sure to check for signals of bad code quality.

Bad code quality means that someone with not enough experience (whatever that means) created the module and there is a higher chance of leaving it to die or not having any vision or determination to expand it into a successful module.

On the other hand, if the code is impressive you learn new ways to code – pieces of code that you don’t understand, search and discover a design pattern – or you learn a new, cleaner way of solving a problem;

How to Prevent This:

• Check if the module has unit tests coverage > 50% of the code (at least for the most crucial problems it is trying to solve); Tests are an indication that the module is maintainable and it was well thought before creation;
• Check the code source of the project setup and take a random piece of code and analyse if you are happy with the quality of the code (this is subjective, there is no perfect code);

4. Security

This goes hand in hand with maintainability but I considered it to be such an important aspect that it deserves its own section.

Security breaches can have costly consequences for your company and investors. It can be a gateway to your app sensitive data.

How to Prevent This:

• Malicious lines of code can make their way into the module code – check the code and the integrity of the author;
• Check the publisher credibility (e.g. you should not use a random dynamodb module, instead use the ones offered by aws directly – unless there is a very good reason);
• Do your due dilligence on the node module;

4. Node Module Size & Dependencies

Something that we don’t look at very often is the package size and its dependencies. Check what this module needs in order to fix the problem.

The node module size has implications in the app loading / execution time. It may not seem much, but with dozens of packages it adds up pretty quick!

Ask yourself the following questions:

• Does it really need this heavy node module dependency for this problem? It may not make sense sometimes (e.g. needing is-odd node module to determine if a number is odd);
• Is it worth having 2MB of code to fix this problem?

Conclusion

I’ll leave the conclusion to you. Let me know in a comment, what is your routine when installing a new node module?

Looking forward to completions if you feel I left something out.