How to keep a healthy package.json

It is common for developers to add npm packages in their applications without knowing what is going on behind the curtains, while also following other bad package.json practices. It is understandable, most of us work in fast-paced environments where we have strict dates to deliver new functionality for our clients. However, as developers, we might face security concerns if we undermine the risk of adding a new npm package, and we should also at the same time keep a healthy package.json. In this article you will learn about the main concerns about npm package management and what we can do to avoid them.

1. Avoid trivial packages

 

A trivial package is a package that does functionality that a developer can easily code themselves. Trivial packages are common, a study found that . This led to thousands of applications breaking - even high-profile applications like React, Babel and Node. This package consisted of roughly 11 lines of code.

Tip: When adding a new package to your project, analyze the cost-benefit and evaluate if you can develop the same functionality yourself without impacting the timeline of the project. Each new package is a new potential point of failure, so it is wise to minimize failures as much as possible.

2. Use SemVer

 

To keep a healthy package.json, first we need to take a look at Semantic Versioning, or

Basically, we start our product release version with 1.0.0. Then, the next release version number depends on the type of changes that we introduce. 

 

Tip: It's recommended to use caret (^) to accept minor and patch updates, and tilde (~) to accept patch releases only. Depending on your project's needs, you may use these restrictions to limit the version of the package your project will use. Check .

3. Avoid pinning dependencies

 

Pinned dependencies are packages which are fixed package versions. This is not recommended since the package will not get latest updates.

"dependencies": {

    "react": "16.8.6"

}

 
4. Avoid adding git repositories as packages

 

There is a way of adding git repositories as packages, but this should be mostly used as a last resort (for example, when the package doesn't exist in npm). If this repository is deleted or updated, you might face major issues.

"dependencies": {

    "react": "facebook/react"

}

5. Look up the package overall health

 

A package health can be defined by three questions: 

 

 - Is this package actively maintained?

 - How many developers use it?

 - Which are the known security issues?

 

All this information can be found in GitHub, you can also look at the npm weekly downloads of the particular package you have chosen to see how frequently it is used among the dev community. There is also the Snyk Advisor tool, which shows all this information in a very friendly UI:

Package management sounds a bit complex, and every team approaches it differently. I hope these points have given you an insight on the most important things to keep in mind to maintain a healthy package.json. There is no perfect way of handling it, but when we know the most common points of failure, we can avoid security risks and keep our application working.

In this article my goal was to give an overview of the most common tasks we can do to manage our npm packages, if you wish to go more in depth I recommend reading Karen De Graaf's article