Lets face it. Every node.js developer (including me) has encountered this problem. You’re in the middle of coding your project at work or your side project, then you thought of upgrading your npm packages. So you type npm install or yarn install. Boom! Updating 123843 packages. Lucky if you haven’t encountered any errors while updating, and if your project still works.
Upgrading npm packages, especially if you have a lot of them, can be a pain in the backside. You don’t know if you’ll update all in one go or update each package one by one. And when you do update in one go, it takes a hell of a lot of time to update. What if you have a lot of packages and you’re scared of updating all of them?
So how do you update your packages if you haven’t updated all of them?
Well, the most recommended fix is to create a new branch if you’re using git. That way when you do update in one go you can easily revert to the original branch and discard the new branch. You can do both update in one go or update one by one, whichever you prefer.
For most packages, if they follow the proper semantic versioning, have patch, minor, and major updates. Patch (in green highlight) and minor (in blue) updates can be updated without problems. Major (highlighted in red) updates could include API changes that can break your app. So you need to check the packages release notes for backward compatibility.
You can also use npx npm-check -u o just npm-check to get the list of available package updates, separated by patch, minor and major updates. And update from there. That said, some brave souls just update in one go and “YOLO”. I don’t recommend that though.
Other developers emphasize the importance of regression tests and a CI pipeline. If proper regression tests and CI pipeline are in place, you can easily check what package updates are causing issues on your application. Having test suites are important especially when its a big project with multiple people working on it. Do have test suites and different kinds of tests (unit, regression, etc.) for your project and have it handle package updates-related tests. That way you won’t have to worry that your application will break after updating.
But, if your project schedule won’t allow it, you have to cut unnecessary stuff like testing. Jamie Zawinski said it on his interview in Coders At Work. They were on a tight schedule with Netscape and he thought that unit tests aren’t critical so they didn’t wrote tests back then. “Are you writing good software or are you trying to be done by next week” – you can’t do both. I agree with him on that regard.
So for your next project, make sure your packages have semantic versioning. Create a new branch if you have a lot of packages to update, and proceed cautiously with the upgrades. Add testing and CI pipeline if your schedule allows.