Dependencies in node project
Tags: node, dependency, npm
Published: 2022-02-22 09:49:41

If you are working on a node project, whether it is backend or frontend you may have to install some package/library in the project. Suppose you are creating an app with `create-react-app`, now your project depends on thousands of libraries you may have not known of. This is because of transitive dependency (we will discuss it later). This will bloat your app with a lot of dependencies.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h1si30u03vougjvo0pjh.png)
So now the question is, what do you think about when you are adding some library to your project. Here are some questions you need to ask when you are adding a library to your project.
## 1. License
The first and most important thing you need to check is the license of the library. Some licenses can be so vague, that will affect your project later if the owner goes for copyright. If you are working for a company, check whether the license is apt for company policy.
## 2. Transitive dependencies
Suppose you are installing `react` in your project, you may think only one dependency is added to your `node_modules`. But if you check the `node_module` folder you will find some other libraries like
- loose-envify
- object-assign
- js-token

Where do these dependencies come from?. This is how npm installs the dependencies. Even though you are not aware of these, it's installed because the `react` library depends on these libraries. These are called transitive dependencies. ie, If `A` depends on `B` and `B` depends on `C`, If you are installing `A`, both `A`, `B` and `C` are installed. [Here's](https://npmgraph.js.org/?q=react) a dependency visualizer that will help you find all the transitive dependencies. This will give you a basic idea of what you dealing with :smile:. 

Transitive dependencies become an issue because, suppose some of the transitive dependencies have some bug/issue, this will break your code. This happened previously and is most likely to happen in the future too. Here are some previous known issues.
- npm left-pad issue ([read](https://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm))
- [Checkout](https://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm) a PR for babel.
- Most recent [FakerJS](https://www.theverge.com/2022/1/9/22874949/developer-corrupts-open-source-libraries-projects-affected) deletion.

At the end of the day, most of the libraries are created by individuals, what they are going to do with the project will be unknown, just be careful while selecting a library for your project.
## 3. Test coverage
You can always check for the test coverage for the library in GitHub. This is very important because the number of test cases or coverage will tell whether the maintainer really cares about maintaining the project for a long time. This also helps to decrease bugs when adding a new feature to the library.
## 4. Documentation
Documentation is very important for the library, you can't go through all code and find how to use it. You can checkout documentation for `django`, `react`, `redux` etc... how well they explained every API with multiple examples. So, select a library that has good documentation for your project, so that you will know the complete functionality of the library.
## 5. Security
It's very hard to check whether the code is secure or not. GitHub has some bots to check potential vulnerabilities, still, you don't know for sure. Something you can do is read some of the files in the library, and check whether it follows some common coding practices such as 
- Variable naming convention
- Is the code is readable?
- Essential comments

Another main issue is even though you go through the whole code and you found it completely safe, the library you installed from `npm` can have a different code. This is because the author can manage different code bases for `GitHub` and `npm`.

## 6. Usage
Every library will have some bugs needed to be fixed or new features needed to be added. We can check whether new `pull requests` are created or `Issues` are properly dealt with. Check whether there is an active community supporting the project. Check for the number of the maintainers also. If a library is maintained by only one maintainer, if something happens to the author new `pull request` or issues will not be properly merged to the library. Check out this [PR](https://github.com/zloirock/core-js/issues/767) for a similar issue.

## Conclusion
The above mentioned are some of the important things needed to be asked before selecting a library. But you can also check for other things such as `GitHub stars`, `forks`, `weekly downloads`, `popularity` etc... These are some basic things, that may or may not show how good is the library. So in my opinion you can check these kinds of metrics after asking the above questions.