Meet Voorhees, a tool to detect Zombie Go dependencies

It’s common knowledge that dependencies are both amazing and terrible. On one hand, they can help you build your product faster by focusing on core logic, offload complex work, fill a knowledge gap, etc. On the other hand, you don’t own the code you are adding and you have to trust the people who maintain them.

Luckily, Gophers tend to be more cautious than others when it comes to using dependencies. The main idea is to pick a dependency if it fits one of those criteria:

  • It fills a knowledge gap that would either take too much time to acquire or that doesn’t make sense for the project to focus on. Example: Third-party API/SDK, image/audio/file encoding and decoding, etc.
  • It’s security or performance-related. Example: Anything crypto-related.
  • It’s rather large or complex and not core to the business. Example: a web framework like gin, echo, fiber.

But even with this you’re not safe. A few years ago satori/go.uuid was the to-go dependency to use if you wanted to generate UUIDs. Sadly, this project is no longer maintained (the owner is MIA) and contains bugs and CVEs. The question is how many people actually know about this? Chances are people are still creating new projects using it because it has 4k stars on Github and/or because they were already using it on another project, so they don’t even check anymore. Last week, Dan Lorenc wrote an article about this type of dependencies, calling them Zombie Dependencies.

This is where Voorhees comes to play. Voorhees (named after everyone’s favorite zombie Jason Voorhees from Friday 13th) is a very simple tool that analyzes your direct dependencies and reports the ones that haven’t been updated in the last X months/weeks. The idea is not to throw stones at maintainers for not updating their dependencies often enough or for not releasing fast enough, but instead to make people more aware of what’s happening with the dependencies they are using.

Voorhees can be used by downloading a binary, through Docker, or can be triggered through a Github Action.

The main question is what should we do when we have a dependency that hasn’t been updated in a while? There is no magic answer to that. Switching to a different library is not necessarily the correct move, and you should not expect a dependency to get weekly or monthly releases. The main thing to do is to look at why this dependency hasn’t been updated.

  • Maybe the repo is active but it’s just that maintainers haven’t cut a release in a little while. This is fine depending on what the changes are since the last release, maybe the maintainers are working on a new major version or feature.
  • Maybe the dependency just doesn’t need more updates. Depending on the type of dependencies it’s possible that the code is basically as good as it can get.
  • Maybe the maintainers have dropped the project. This is the main one to look for.

Ultimately you want to check if there is any sort of activity in the repository.

  • Check if the main branch is still getting commits at all.
  • Check if there are issues reported and if they are being addressed.
  • Check if there are PRs opened and if maintainers are looking at them or interacting with them.

Ultimately you should see a red flag if there are many PRs and issues opened with no maintainers looking at them. If that’s the case you might want to start looking for a potential fork or for a different library. Otherwise, you can tell Voorhees to either ignore the dependency or you can set a different expiration time for this specific dep. If there is some activity in the main branch but no releases in the last 6 months, maybe you can increase the date to 1 year and see if something changed by then. If not, you can look deeper into it and maybe reach out to the maintainers.

The current version of Voorhees only looks at direct dependencies and the date of the latest release, but I already have many ideas of useful features that can be added:

  • Detecting direct circular dependencies.
  • Adding a “smart” option that would leverage the Github API to potentially filter out deps that have an active branch, check if issues / PRs get addressed, etc.
  • Find a way to properly report outdated indirect dependencies (this would be noisy, but could be useful to know what we’re adding). Maybe limit this to a depth of 1.

To get started with Voorhees, head over to the Github repository.

Staff Engineer at Abstract, Splice. I love Go, and I love Git. https://melvin.lahttps://linkedin.com/in/melvinlaplanchehttps://github.com/Nivl

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store