Keeping up with ... web package versions

Web development has changed dramatically over the years. We've seen major changes in how dependent libraries or frameworks were included in a website as years passed.

The way you'd do it 7 years ago, you would include a CDN link, or even copy the packages over to your website's /lib folder. Today there are a lot of ways to manage packages, depending (pun intended) on what type of application you're trying to build.

Let's take the node modules approach. You need a package manager (like npm, yarn etc.) and a bundler (webpack, rollup). But the hardest thing they're trying to accomplish is to rid you of managing different versions of libraries.
However, you should consider updating your application dependencies regularly in order to keep it secure, bug-free and to potentially improve performance (all these just by bumping versions in a JSON file).

But upgrading library versions in a 20-line package.json file is not an easy job. You could easily take the latest version of each library, but then you might get conflicts or breaking changes.

Below, I compiled a few tips on when to upgrade, when to skip, and some tips on upgrading.

When to upgrade

• The new versions of dependencies have security updates
• Little to no breaking changes are announced by the upgraded version's release notes
• You have the time to do smoke tests of the main application features (you should not do a library upgrade a few days before releasing to production)
• Scan your modules/libraries regularly with a module security scanner, such as RetireJS, OWASP Dependency-Check, Snyk.
• A library stops receiving security updates & patches (such as AngularJS 1.x) - in this case, you should plan this as a major work item.

When to skip the upgrade

• There are no security updates on the dependencies
• You plan on releasing in production in a few days and you don't have time to test the changes well. You should still do the upgrade in a future release
• A lot of breaking changes & incompatibilities are presented by the upgraded library. If the current major version will still receive security updates, you should stick with it & plan to upgrade to the next version in your backlog, or move to a more stable library entirely.

Tips when upgrading

• Check the release notes of the major & minor versions for breaking changes, and write them down
• Check if other libraries that depend on the one you're upgrading are still compatible (should be written in their release notes, or readme)
• Modify your code to comply with the breaking changes & test the features that were modified
• Smoke test each part of the application that uses features from an external dependency (e.g. date pickers, material components - each different component should be tested)

Other tips

• Don't include a library for anything. You don't have to reinvent the wheel, but you can definitely write 30 lines of code for some functionality instead of including a library just for that. You'll thank me when the library becomes deprecated or will no longer be compatible with React v.Next a few months from now.
• Stick with libraries & frameworks with a clear plan of future updates, such as major ones (Angular, React, etc.). Also, libraries backed by a commercial company are in less danger to perish due to missing contributors.
• Instead of including a small library for each feature, use a major library or framework that comes with most of what you need (e.g. Material, Bootstrap, etc.) These libraries will usually update & test for breaking changes when a new version of other frameworks come out (for instance - New Angular version comes with new Angular Material).

Last tip

• Make the dependencies security scan a part of your Continuous Integration / Delivery process, and plan these upgrades in your backlog.