Golang modules - everything, even your application, is a module

I’m new to golang modules. Here are some of the things that I wish I had known when I started using them.

There is no reason to set GOPATH

One of the things I struggled with was how to reconcile modules with the single workspace directory recommended in the golang docs and what was previously where GOPATH would point. With go modules you wouldn’t normally set GOPATH.

Everything is a module

Everything is a module. Even your application. This is something not immediately obvious or mentioned anywhere.

Every module has to have a name

If you aren’t planning to import or share your application/package then you can use a non-repository name like myapp. When you initialize go modules you can do:

go mod init myapp

If you’d like to share this as a module you’ll want to use its web location instead like:

go mod init github.com/user/repo

Packages need to be fully qualified

If you had a subdirectory of your application called mypackage then you’ll have to adjust your imports from “mypackage” to “myappmodulename/mypackage”

Module dependencies are stored at $GOPATH/go/mod

If GOPATH is empty, which it typically is if you are enabling go modules support, dependencies are stored in ~/go/mod. These dependencies are shared across all of your go applications that are using go modules. (Unless you want relocate them which is possible but not discussed here)

You can keep using a single workspace

If you’d like to keep using the single workspace approach you certainly can, but don’t have to now that modules support exists.

To keep using the single workspace approach just place your go applications in the same sub directory as you did before, without setting gopath. When you build in each folder the dependencies will be fetched and stored in the shared location discussed above.


Again, I’m new to go modules, if you see something not quite correct here please comment below and I’ll try to make corrections.