A solution for picking and upgrading the NPM packages

Lasting first that “every package you add means another dependability on an external source.”

In this solution, we will go through challenging topics like how to pick an npm package to add to your project and how to keep them updated with less hassle in the development and maintenance process. Also, I have assumed you have basic knowledge about Javascript libraries like React.

Based on my experiences, I can suggest dividing packages into two categories:

• Core packages: Those are packages that come from trusted resources and so many developers spend a lot of effort and their time like React, Material-UI, Redux, and Webpack. These packages are usually fundamental for your project architecture.
• Trivial packages: Those are some shortcuts that you want to add to your project to save sometimes or not to re-do it. They are usually won’t impact your architecture.

How to select an NPM?

Finding a suitable package that is a good answer for your need a key metrics for picking a package or rejecting that. The following items can be very basic norms to consider a package is good enough or not:

Ask yourself if you really need the dependency or can be done with a function? if you can just write a function and avoid adding another dependency, just do it because it worth spending a short time to do something then adding an external depencies.

Make sure the documentation is clear enough for your team. It is really important that the document which is written by the developer of the package is clear and understandable for your team. It can be possible to reach by following steps:

• Know more about the package: It is important to know the features or capabilities of a package before choosing it.
• Read the home page: if it doesn’t have a home page, this is a sign that the project is not maintained, and you should avoid it.
• Review the project readme and instructions
• See who’s responsible and contributors

Check the ratings metrics and popularity of the package by the number of installations. These values can be metrics to see how the development community trusts to use it.

Check if it’s still actively maintained? It is very common that a very popular package is not actively maintained and their last update is referring to months or years ago. This means you might add a highly potential legacy to your project. Then it would be good to look for:

• What’s the maintenance history of the package?
• How many releases have there been?
• Get the issues list of the package by npm bugs
• Has the creator maintained a regular schedule of fixes and upgrades, or has it been a while since anyone has done work on the package?

Verify the size of the package if they are used client-side. There are many different tools out there that you can use to evaluate a package size and the effects those might have on your projects. Following you can see two puplare tools:

• Bundle-phobia:
• npm-trends

Carefully choose one of Dependencies or devDependencies. For sure you know it better, but I have seen many times that mistakes like this would cost you in bundle size then just keep an eye on it.

• Dependencies are “Packages required by your application in production”
• DevDependencies are “Packages that are only needed for local development and testing”

Besides there many other good metrics that you can still take into considerations like Check the security issues & vulnerabilities and license of the project or Carefully check the peer dependencies shows up when you expect the projects that include your package also have that package as a dependency.

Upgrading the Policy for NPM Dependencies

Finding a reliable solution to keep the NPM dependencies up-to-date is one of the key decisions for the development team because they need to compromise between dealing with new changes, updates or features with the development roadmap, which usually ignored by the product managers/owners and they will try to postpone them as far as possible.

Very straightly I can propose the following solution:

1. Update at regular intervals based on what I have seen once every sprint is a good interval to update and less changes you can have.
2. Testing the new updates before committing
3. Look for (and consider) alternatives, including micro-dependencies
4. Requirements of Update:

• Familiarize yourself with dependencies through different applications, and keep them up-to-date
• `yarn audit`: this will show you the dependencies you’re using that are not up-to-date with their latest security patches
• Check if your dependencies are really used? If some of them aren’t, just remove them by `yarn remove some-dependency`
• Ask yourself if you really need the dependency?
• Find outdated packages and dependencies
• What are the changes? by look for a CHANGELOG file, releases, or even better a migration guide.
• Test, test, and test again such that each time you’ll update a (group of) dependency, you should run your tests, check that your builds are still working, do some manual test on your application

Which packages should be updated?

• The new version has features you want to use. For example, when React released the version with hooks, upgrade this one.
• There’s a certain bug you are experiencing that can be solved by updating the package. Check on the GitHub page, if so then upgrade.
• When you’re using another package that’s asking for a newer version of an already installed package. Usually, this will be indicated in the peer dependencies.
• Sometimes a package will publish a newer version with significant performance improvements.
• When a new major version has just been released, just wait for 1 or 2 months because there’s always a risk that some overseen problem comes up just following a release.

To bear in mind

• VERY IMPORTANT RULE: Do not wait too long before updating the packages that fit in the above list. The longer you wait, the more breaking changes might be released.
• Survival Rule: never forget what to do when your application doesn’t work anymore. Just remove and reinstall all of your node modules.