Everything you need to know about Go modules

In this video, I'm going to tell you everything you need to know about Go modules. Go modules are used for dependency management in Golang, so if you've used Node modules, Gradle, or Maven before, it's Go's answer to all of those things. If you're new to dependency management, writing larger Go projects, do not worry, by the end of this video you'll know everything you need to know.

Let's imagine this is an application you've written. It's composed of small packages that make up the application. You have logging, you have a web server, you have a CLI, config, encryption, and some sort of message bus. It's reasonable that you may use standard library packages or write your own logging, web server, or CLI. But it'd also be completely usual to pull in some packages from the internet or from other places around your company for these other things.

For example, if you are trying to satisfy FIPS requirements, you have to use a specific encryption algorithm. If you want to use Kafka in your application, it would be kind of crazy to try and implement your own Kafka library.

Whenever you import other people's code from the internet like this, you become dependent on it. It becomes a dependency. Being able to do this is a great thing, and we shouldn't discourage it too much. It means we can use code from experts.

However, we must also acknowledge that every time we import code from a third party we introduce a risk. What if their GitHub gets hacked, someone puts a backdoor in the code intentionally or even worse perhaps someone introduces a backdoor unintentionally. A really famous example of this is log4shell - a vulnerability that was introduced by the log4j java library. It meant thousands of projects were susceptible to a vulnerability where you could potentially get access to an entire system via a logging library.

It's therefore really important that we can track which software libraries we are using, track which versions of those libraries we are using, ensure those versions have not been changed. They are predictable and they are what we expect them to be. Also if you're a company and selling yourself, it can be important to see which libraries you were using to ensure you are adhering to their license.

It might surprise you to know that when Go launched in 2009 it did not have any means of dependency management built into it. Go engineers would set a variable called GoPath and we'd reference all of our dependencies relative to that GoPath. As the need for dependency management became clear lots of community projects appeared such as GoDep, Glide, and eventually the official experiment for dependency management, which was called DEP. DEP was particularly interesting because this was run by the Go team.

The Go team created this and they effectively used it as an experiment before committing to an API which would become Go modules. As you can see all these projects are archived now and Go modules is the way to go for dependency management after its introduction in Go 1.11. I still wanted to show you these because you will occasionally still see projects around the internet that use these older versions of dependency management.

So enough history, what actually is a Go module? Well according to the official Go site a module is a collection of Go packages with a Go mod file at its root. The Go mod file defines the modular paths, which is also the import path used for the root directory. It describes its dependency requirements, which are the other modules needed for a successful build. Each dependency requirement is written as a module path and a specific semantic version.

This is quite a mouthful. We'll talk about semantic versions shortly, but to try and make sense of all this, let's jump into a Go project, create a Go module, and add some dependencies to it to see how everything clicks together.