Package upgrades can get tricky, and they may get even more tricky if there are loads of packages in an application. Which one breaks the app? Which one breaks another package? Which ones should be upgraded first or before another package? What packages should be upgrade together?
Here are a few rules of thumb that I go by while upgrading package dependencies. I have found that these help simplify package upgrades a good amount.
From what I’ve found, the package
npm-check is the best tool for my workflow. It helps to speed up package upgrading. That package will organize the dependencies in a “patch, minor, major” format. Seeing packages in that format, is the flow to upgrade packages.
Patch and Minor Upgrades
These should be perfectly compatible if the package author(s) are following semantic versioning correctly. It’s pretty much a 99.9% guarantee that these won’t break. I would group all patch and minor upgrades together. For a sanity check, regression testing is a valuable option.
This one I just learned recently. Integration upgrades are packages that are coupled with third-party services. I think integration upgrades should be completely separated from the rest of the flow, becausae the breaking changes could appear in the package and even in the third party UI configuration.
Upgrading packages from patch, minor, major, and to integration simplifies a potentially complicated task. Through this flow, I haven’t seen things break nearly as often in comparison to before using this process. For me, this upgrading process is a good flow to follow.