Go Modules Experience Report

15 Apr 2019


  • Side effects are surprising and hard to control.
  • Different commands perform different actions on go.mod, which are hard to reason about.
  • Official and Google projects aren't using semantic versioning, creating uncertainty about whether that's the direction of the ecosystem.
  • Future of vendoring is ambiguous.
  • Modules pull in more transitive dependencies than per-package vendoring.

On Let's Encrypt's Boulder project we decided it's time to move to Go modules. We've been using godep to vendor our dependencies for a long time but it's no longer maintained. We vendor our dependencies to ensure that we can always deploy, even if an upstream dependency becomes unavailable.

I wanted to separate the task of switching to modules from upgrading any dependencies. I wanted to be easily able to separate any bugs based on changing dependencies from any bugs based on switching to modules.

I started with Boulder at de15c267 go mod init:

In a project already using an existing dependency management tool like godep, glide, or dep, 'go mod init' will also add require statements matching the existing configuration.

This created a go.mod with versions matching what I had in Godeps.json. So far so good. I committed it.

Next I ran go mod verify to check that