Keeping Elixir Packages Updated

It is good practice to regularly make sure dependencies in your project are up to date so that you are running the latest and (hopefully) greatest code.

In Elixir we use Hex to manage dependencies and it comes with some awesome tooling to help make sure we’re up to date.

mix hex.outdated

The first command is mix hex.outdated. The one liner from the docs is;

Shows all Hex dependencies that have newer versions in the registry.

When you run this command you will get something back like this;

Dependency  Current  Latest  Update possible
credo       0.8.3    0.8.4   Yes
dialyxir    0.5.0    0.5.0
distillery  1.4.1    1.4.1
edeliver    1.4.3    1.4.3
ex_doc      0.16.2   0.16.2

For this project I can immediately see that credo can be updated. The reason the update is possible is because my mix.exs file covers a newer version that I just haven’t set up yet.

If my mix.exs was set up to only allow a package to update to a certain version and the registry has a newer version than we would see something like this;

Dependency     Current  Latest  Update possible
ecto           2.1.4    2.1.4
ecto_enum      1.0.1    1.0.1
facebook       0.9.0    0.13.2  No

In this one we can see that the facebook hex package is out of date but we can’t simply just run mix deps.update (I’m going to explain that shortly).

If we look in our mix.exs file we can see that our facebook dependency is set to {:facebook, "~> 0.9.0"}.

If you haven’t seen the pessimistically greater than or equal to operator before I’ve written about it on an article on Gemfiles.

The quick explanation is that saying “~> 0.9.0” is like saying. “Allow any version that is greater than or equal to 0.9 to be installed, so long as the version is lower than 0.10”.

The fix here would be to bump up what we expect :facebook to accept. Of course you should test everything after doing updates, and be especially careful in case there was a reason you locked to a particular version.

mix deps.update

So we’ve seen there is some stuff we could update, luckily the process of updating hex packages is very straight forward.

From the docs;

Updates the given dependencies.

mix deps.update will update your dependencies to the highest available version that matches your mix.exs requirements as well as requirements made by other packages that your packages depend on.

If mix deps.update fails it should give you enough information to start searching for a solution. Often it is because you require a version of something that another package can’t use.

You run it by passing in the package you wish to update, from our earlier example I could run mix deps.update credo. If I was feeling devil may care I might even update everything at once with mix deps.update --all.

Umbrella Projects

If you try and run mix hex.outdated in an umbrella project you will only get results for the hex packages you’ve directly installed in your mix.exs.

If you don’t relish the idea of going into each of your individual apps and running the command then you can run mix hex.outdated --all. This isn’t a perfect solution because it returns all dependencies, including ones you didn’t actively specify.

Because you see everything in one list it is impossible to work out which are things you’ve actively relied on and which are dependencies of dependencies.

Another solution is to write a quick bash script, which I’m a big fan of.

I created a file called check_deps.sh

#! /bin/bash

for app in apps/* ; do
  cd $app
  mix hex.outdated
  cd -
done

Set it to be executable with chmod +x check_deps.sh then I can run it with ./check_deps.sh. This will loop through all my apps (in an apps directory) and run the mix hex.outdated command on them.