Rachelle Rathbone

Noob Tidbit #1: Update Your Darn Packages

One of the Many Things I wish I knew when I first started programming

November 23, 2019

Nood tidbits are a series of short posts that cover a range of things that I've discovered in my first few years of engineering that have been game changers for me. Each tidbit it something that I wish I wish I had known about when I first entered this industry.

As embarrassing as it is to admit it, during the first two years of my career I rarely updated npm packages. The reason is simple: I didn't recognize the importance of it. When I did update a package it was usually because I started running into weirdness of some sort, which forced me to update the problematic package, sometimes packages, to its most recent, stable version. How did I miss such an important piece of information and continue to overlook it for so long? I went to a coding bootcamp and then was essentially a lone soldier at the startup I worked at. Chances are, if you went to a bootcamp or if you find yourself in your first gig with no one to guide you or give you feedback, you too may not realize that this is something you should be doing on a somewhat frequent basis.

Before I go on to explain why this is a practice you should adopt I'd like to add that in no way am I discrediting bootcamps. With such a limited time to cover such a broad range of concepts, it's not surprising that some things get missed along the way. Also, for all I know, maybe one of my instructors did mention it at some point but my head was so overloaded with content that updating packages was a piece of information my brain decided not to hold onto at that point in time.

Why Should I Update My Packages?

There's typically 3 reasons you want to stay on top of those package versions, both globally and locally:

  • Stability: As I mentioned previously, this is what forced my hand to update a package in my first couple of years. If you're running a really old version of a package, chances are that you'll start to notice some weird things happening in your application at some point. If you are running old versions of packages and have noticed some peculiar things going on then it's probably past time that you take a few minutes to look at your package versions and see what needs to be updated. More info on how to do that in the following section.
  • Usability: If you want your users to have a flawless experience when using your app then don't let them deal with an app that's running on old versions of packages. If your app is unstable, then it's also probably not very usable. Most people don't have patience for buggy apps and those who run into problems may well never come back.
  • Security: Often, when a package is updated, the new version will include a bug fix or resolve a potential security issue. If you never update your packages, your app may be riddled with bugs and could leave you vulnerable to attackers who are actively looking for sites with holes that are created through poor package maintenance.

How Do I Update My Packages?

Updating your packages is generally pretty simple, however, if you're running really old versions because, hey, you didn't realize this is something you needed to do, then you might want to take a more tactful and slower approach than the one that I'm about to suggest.

A good starting point, even if you're running on the versions you installed when you first created your app, is to run npm outdated. This will give you a list of all the packages you have installed that have since released newer versions.


The first column, 'Package', lists the names of the packages that need to be updated, followed by the 'Current Version' you have installed. The 'Wanted' and 'Latest' columns can be a little confusing but according to the npm docs:

  • latest is the version of the package tagged as latest in the registry
  • wanted is the maximum version of the package that satisfies the semver range

And location is pretty straightforward. It's just the directory where the packages are installed.

Now if there's nothing too scary looking i.e. there aren't major versions changes (for more info on what each of the numbers stand for check out my post about semantic versioning), the quickest approach to tackling updating all your outdated packages is to run npm update. It may take a couple of minutes for your packages to update but, once they're finished, if you run npm outdated again, you shouldn't see anything being returned.

A word of caution, even if you're packages are fairly up-to-date, sometimes a package update may contain a bug because, nobody is perfect and bugs will forever invade our programs. When working on updating packages, it's always a good idea to work on a feature branch and then test your app to make sure everything is working as expected. If anything is broken run git stash to remove the updated packages, then remove your node_modules directory and reinstall them by running rm -rf node_modules && npm i or rm -rf node_modules && yarn. Even if you stash your changes your node_modules directory will still have the most recently installed versions so it's important you delete that directory and then reinstall the packages you originally had.

If you find yourself in this situation, unfortunately the process of updating can become a little more cumbersome. You could always got through and manually update one package at a time or you could follow a process similar to the following:

  1. Break the packages up into groups. This will help you narrow down troublesome packages that could be creating the problems in your application. You could do this be simply working your way down the list and picking an arbitrary number to update each time or you could group the packages by type. For instance, you could update all the jest packages in one group, react packages in another, webpack packages and so on. Just remember to run your app after each group of updates. If everything looks good, add and commit your changes. If something breaks, revert the update and then start digging deeper into the packages included in that group.
  2. If something broke you're at the point where you'll probably want to start updating packages one-by-one. It's not fun but it will help you narrow things down until you find the package/s that are creating issues in your app when you try and update it. Either run through the list in the group from top to bottom or, if you suspect you know which package may be causing the issue, check out the 'releases' tab for that package in github and read through all the changes that have been implemented since the version you have installed to the version you're trying to install. Try updating it and, if something breaks, see if you can pinpoint which update may be creating the issue in your app and then install the version before that. If you can't find the version that's breaking your app then maybe skip updating this package for the time being and keep your eye out for the next release.
  3. Rinse and repeat!
  4. As an additional step you could update your package.json for more control over semantic versioning.

Some Alternate Commands for You to Try

Both npm and yarn have some additional commands that you can use to try and help you in, what can be, a very tedious process.

Yarn
  • yarn upgrade-interactive: this will bring up a list of all your outdated packages and allow you to scroll and cherry-pick which packages you want to update. This makes the grouping process far easier. One important thing to note: selecting a bunch of packages and hitting enter will update your package versions in node_modules but it will not update the version in your package.json file. While this is a fun feature this aspect makes it pretty useless. If you ever need to delete your node_modules directory and reinstall it, you'll be installing all those old package versions. If you want to use this feature of yarn, make sure you update your package.json file to match the new versions you're installing. However, even if you choose not to use it because it doesn't update package.json, it's still useful to run if you're using yarn because, as seen in the screenshot below, it has a handy color guide that visually tells you which updates should be safe, which ones may cause problems, and the ones that you will probably want to be super-dooper careful with when updating.

  • yarn why <package_name>: If you've been working on a project for a while or a new to a project, there's a good chance that, as you're looking through the list of packages that need to be updated you'll ask yourself 'wth is that and why are we using it?' yarn why will help you understand how and why it's being used in your application.


NPM
  • npm info <package_name>: Run this command to get information about what a package is, a link to the github repo, its latest version, most recent publication and a number of other details. Hot tip: if you hold down command on Mac (and I'm guessing the windows key on Windows...¯\_(ツ)_/¯) and hover over the link to the github repo, it will turn the link into a hyperlink that will open a tab to the repo in your browser! :)


  • npm info <package_name> --json: if the above command doesn't give enough information for you, try running this command. You'll receive a json object with much in-depth info about the package you're looking into.
  • npm info <package_name> <key>: if the object from the command is too much to take in but you know/find a specific key you want to look at, you can specify that in this command to only get that data back. For instance, if you only want to look at the versions of the package, run npm info <package_name> versions.


However you choose to go about it, staying on top of package updates is an important part of any application and, the more frequently you do it, the less hassle you'll be faced with upon each iteration.
...
© 2023, Rachelle Rathbone