Managing Third-Party Dependencies
At its roots, dealing with legacy systems means dealing with dependencies, each with its own set of potential problems. You’ll have to understand whether your dependencies are healthy, poorly maintained, or abandoned altogether. Every application depends on other libraries and each dependency may depend on libraries of its own, often requiring specific versions. Developers need a way to manage these dependency trees so each language has a reliable way to list dependencies, compute the right versions that fit together, and work with the result.
Elixir has a package manager called Hex.[40] Adding Hex dependencies to a project is quite easy but it does not mean it should be done carelessly.
Any dependency becomes fully married to your application, for better or for worse. You may need to get support for it or even debug it yourself. In extreme scenarios, a dependency can eventually become fully unmaintained, forcing you to to either maintain or replace it. While you don’t need to worry about the most prominent projects in the community being abandoned, thinking about each added dependency carefully is a helpful exercise. We offer the following advice:
-
Before adding a dependency to your project, take a look at its codebase and ask yourself “Would I be able to maintain this library if I had to?” Look for documentation and especially for a test suite.
-
Is the functionality that you need complex enough to warrant bringing in an external library, which often comes with its own set of features? Sometimes a little strategic copying is better than adding a full dependency.
-
See if the library is maintained. Be forewarned: a lack of activity does not mean the code is unmaintained—sometimes a library is simply complete.
-
See if the project has a license you can work with.
-
If the project is very active, check if it maintains a CHANGELOG so you have a clear path when updating versions.
After you add a dependency, eventually you will have to update them. The simplest way to get a real-time status of your libraries is the mix hex.outdated command. From the root of your application, run the following command:
| | $ mix hex.outdated |
You should see something like the following:
| | Dependency Current Latest Update possible |
| | benchfella 0.3.4 0.3.5 Yes |
| | bypass 0.7.0 0.8.1 Yes |
| | cowboy 1.0.4 1.1.2 No |
| | credo 0.6.1 0.8.5 No |
| | decimal 1.3.1 1.4.0 No |
| | earmark 1.1.1 1.2.3 No |
| | ex_doc 0.17.1 0.17.1 |
| | excoveralls 0.6.5 0.7.2 No |
| | gettext 0.13.1 0.13.1 |
| | httpoison 0.11.2 0.13.0 No |
| | inch_ex 0.5.6 0.5.6 |
| | logger_file_backend 0.0.10 0.0.10 |
| | phoenix 1.2.4 1.3.0 No |
| | phoenix_ecto 3.2.3 3.2.3 |
| | phoenix_live_reload 1.0.8 1.0.8 |
| | phoenix_pubsub 1.0.2 1.0.2 |
| | plug_logger_json 0.3.1 0.4.0 No |
| | postgrex 0.13.3 0.13.3 |
| | |
| | A green version in latest means you have the latest version of a |
| | given package. Update possible indicates if your current requirement |
| | matches the latest version. Run `mix hex.outdated APP` to see |
| | requirements for a specific dependency. |
You can get more information about upgrading a particular package by giving its name to mix hex.outdated:
| | $ mix hex.outdated phoenix |
| | There is newer version of the dependency available 1.3.0 > 1.2.4! |
| | |
| | Source Requirement |
| | mix.exs ~> 1.2.4 |
| | phoenix_live_reload ~> 1.0 or ~> 1.2-rc |
| | |
| | A green requirement means that it matches the latest version. |
If you decide to update a dependency such as Phoenix, set a moment aside to read its CHANGELOG, assess the risks behind the update, and estimate the efforts the update would entail.
While it is important to keep your dependencies relatively up to date, your team also needs to deliver value to your clients so you will need to find a balance between upgrading too frequently and never upgrading.
The only time an update is strictly necessary is when there is a security release or the version you are currently running on has a critical bug. Luckily, Hex also includes a task called mix hex.audit that let us know whenever a package is retired. Let’s see how to audit Hex dependencies. For example, Distillery v1.3.3[41] had a package retired because important functionality was broken. Say your project depended on Distillery 1.3.3, a dependency for building deployment releases. Running mix hex.audit would give you:
| | $ mix hex.audit |
| | Dependency Version Retirement reason |
| | distillery 1.3.3 (other) Custom commands are broken in this release |
| | Found retired packages |
If there are retired packages, mix hex.audit will exit with a non-zero status, which can be useful if you want to integrate the command in your continuous integration pipeline.
Finally, if you like to live on the leading edge and give valuable feedback to the community and the projects you use, you can run beta versions and release candidates in staging and even use the duplexing technique we learned in Moving Incremental Releases into Production to test upcoming releases.