Skip to content

Instantly share code, notes, and snippets.

@mcalthrop
Last active June 10, 2022 12:51
Show Gist options
  • Save mcalthrop/7d2390aa3ce03a770546e798cfb50202 to your computer and use it in GitHub Desktop.
Save mcalthrop/7d2390aa3ce03a770546e798cfb50202 to your computer and use it in GitHub Desktop.
Thoughts on node package maintenance

Thoughts on node package maintenance

I've worked on a wide variety of node-based repositories in many organisations, and one of the questions that keeps coming up is this:

How do we effectively keep our node packages up to date?

After trying several different ways, I have recently come across a solution I have found really effective.

What's the problem?

Node package versions need to be kept up to date – it's a basic house-keeping task that you should be doing if you are not already.

What we really want to avoid is a scenario like this:

  • node packages have not been updated in a long time
  • you need to update a package to take advantage of a new feature that you require (for example)
  • you update that package, and likely other related packages
  • and discover that your build is broken
  • and it takes hours to discover the cause and implement a workaround or fix

I have experienced this exact scenario, and it's not fun.

It even happend with minor version package updates – the package maintainer had not quite adhered to semver principles... 🙄

The best solution (that I've seen so far)

Use the npm-check-updates package to get the latest minor version of all your packages.

In its simplest form, it can be used like this:

npx npm-check-updates --upgrade --target minor

The package-lock.json then needs to be updated to reflect the changes in package.json:

npm run install

And I have also discovered that if the package.json file contains a resolutions section, I need to run npm ci:

npm ci

And if you need to exclude a package, the --reject option can be used; the options section provides more information.

Scripting it

Put all the above commands in a shell script, and call that from a new entry in scripts in package.json.

The script could also do the following:

  • run some tests to verify no regressions have been introduced
  • create a timestamped branch
  • add and commit package.json and package-lock.json
  • push the branch up to the origin

Then create a pull request, review & merge.

And of course run the code locally as a sanity check 😎

Automation

The solution so far relies upon the development team to remember to manually run the script on a regular basis.

With a bit of effort, you could use your repository's tools to automate the process to run periodically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment