On project maintenance

Consider the following scenarios:

  • You maintain a legacy project or your once-greenfield project has now turned a year (or two) old
  • You’ve been busy programming and have been pummelled by project admin

Under the stresses that come with the combination of these two scenarios, software developers often overlook one critical aspect to a successful, future-proof project: external package-maintenance.

I recently sat down and wrote an email explaining how I go about package-maintenance and thought it would be useful to write up those notes and share them with others.

The tech world moves quickly; new code styles, frameworks and best practices evolve in the blink of an eye. Before you know it, the packages you'd installed the previous year are no longer documented and there aren’t any blogposts describing how to upgrade them to their latest versions. Nightmare.

My general rule of thumb to avoid this ill-fated destiny is to set aside some time each sprint to upgrade packages. The process isn’t really involved, but it can be time-consuming if you upgrade a handful of packages at once and find that one of them breaks your code. You then have to go through each, one by one, downgrade and figure out if it’s the culprit.

My upgrade procedure (in this case using the yarn package manager) is:

  • Check which packages are due for upgrade - yarn outdated
  • Look through the READMEs for each of the outdated packages and check if any of the changes are likely to impact your codebase
  • Upgrade those packages that don’t appear to significantly have changed - yarn add clean-webpack-plugin@latest or yarn add clean-webpack-plugin@VERSION_NUMBER to install a specific version
  • Run the project’s test suite and check if the application still works. Fix any issues as required
  • Repeat for packages that have significantly changed

Tom Szpytman is a Software Developer at Encodo and works primarily on the React/Typescript stack