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 trivial packages make up 16.8% of their studied npm packages. Trivial packages are used because they are perceived to be well tested implementations of code, however only 45.2% of trivial packages even have tests.
This data is concerning considering the risk one takes when adding a new package who can be exploited. One example where adding a trivial package went wrong is the left-pad package. On 22 March 2016 its creator, Azer Koçulu, decided to unpublish several of his packages in npm, including left-pad. 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 SemVer. Below is a chart given by npm explaining how SemVer works:
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 SemVer cheatsheet for more information.
If we follow SemVer, we can handle major updates manually which are more likely to break our code. If you’re not sure if you’re following SemVer ranges correctly check the SemVer calculator.
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: https://snyk.io/advisor/
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.
How do you follow a healthy package.json? Let me know in the comments :)
For more information, check Karen De Graaf “Guide to managing npm packages in your package.json”
References:
Rabe Abdalkareem, Olivier Nourry, Sultan Wehaibi, Suhaib Mujahid, and Emad Shihab. 2017. Why do developers use trivial packages? an empirical case study on npm. In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2017). Association for Computing Machinery, New York, NY, USA, 385–395. https://doi.org/10.1145/3106237.3106267
How one programmer broke the internet by deleting a tiny piece of code https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code
How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript https://www.theregister.com/2016/03/23/npm_left_pad_chaos/
