GoLang without a PATH (Intro to Go Modules)
Tags: go, beginners
Published: 2019-02-27 16:04:52

---
title: GoLang without a PATH (Intro to Go Modules)
published: true
description: Unshackle thyself from thy GO_PATH, with go modules
tags: Go, GoLang, beginners
cover_image: https://thepracticaldev.s3.amazonaws.com/i/8628cadonzm5094gg6tn.jpg
---
<h3>Unshackle thyself from thy GO_PATH, with go modules</h3>

We received the gift of Go Modules, with Go 1.11. Go modules are great for several reasons, but My <b>FAVORITE</b> reason is the fact that it allows you to run your Go code <b>OUTSIDE OF YOUR GOPATH</b>. Let’s talk about how to use them.
<h4>From scratch</h4>
To start a new project as a Go Module: Create the project directory, write a simple main.go (you can find some simple examples on [**gobyexample**](https://gobyexample.com/)), and then run```$ go mod init <project-name>```Now you’ll have a <i>go.mod</i> file. If you’re familiar with <i>npm</i>, I essentially think of this as your <i>package.json</i> when you are using <i>npm</i>. This is where all of the imports that your module needs, are specified. It’ll be initialized with your new module being declared at the top of it. Now run the following command, inside of your new module.```$ go build``` Now, it’ll actually work without being in your <b>GO_PATH</b>. It will also pull in all of the <i>required modules</i> and list them in your <i><b>go.mod</b></i> file. It will use the most up to date version of the package if not otherwise specified. Also, you’ll actually see output from the build process, rather than just having the executable. If you view the mod file, you’ll see that it also lists out indirect dependencies that your module is using. Running <i><b>go build</i></b> will also create a <i>go.sum</i> file, which we’ll talk more about in the next section. Another very important command to remember is ```$ go mod tidy``` When you run <i><b>go build</i></b>, it does not apply the dependencies that your tests are using to your <i>go.mod</i> and <i>go.sum</i> files. Running <i><b>go mod tidy</i></b> will make sure that all dependencies, including the test dependencies, are accounted for.

Now your <i>go.sum</i> file contains your built dependency versions and their hashes. Again if you’re familiar with <i>npm</i>, you can imagine this to be something like your <i>package-lock.json</i>. You don’t necessarily have to commit your <i>go.sum</i> file, but I’d highly recommend that you do. The hashes make sure that if you are importing a module of version <i>v1.2.3</i>, that the specific release wasn’t tampered with. There could be a mess up on the maintainers/contributors side and some change was forcibly pushed into the exact same version, making that version corrupt. Your hashes will defend you from that.

<i>Go.sum</i> also essentially tracks the history of the packages that you’ve used. If you decided to use <i>v1.2.2</i> after already having used <i>v1.2.3</i>, <i>go.sum</i> will add the version hash of <i>v1.2.2</i> and still maintain the hash of <i>v1.2.3</i>. This is done so that if you decide that you want to bump back to the higher version, you will be able to continue using the same package that you previously depended on.

> <b>NOTE:</b> If others need/want to use your module in their projects, it will just work for them if they are using Go 1.11 or later. Some previous versions <b>MAY</b> also work without any issues. If you want to make sure that it <b>WILL</b> work on older versions, you must <b>vendor</b> your dependencies. All of your dependencies that you are using should be stored locally in your <b>GO_PATH</b> under something resembling <i>/go/pkg/mod/</i>. To assure that all of those dependencies are installed for others depending on your module, run the following command ```$ go mod vendor ``` inside of your module. now you’ll see that you have a <b>vendor</b> file in your module.

<h4>From an existing project that isn’t using modules or go deps</h4>
Sooo now you’re wondering how you’d migrate one of your existing Go projects into a module. Run <i><b>go mod init</i></b> on your existing project, and now it is pretty much a module but not yet finished. There is just a little tidying to do. Next, run <i><b>go get ./…</i></b> and it will assemble all of your projects dependencies into your mod file. Finally run <i><b>go mod tidy</i></b> to get all the rest of the dependencies in your project.
<h4>From existing project that is using go deps</h4>
Nooooow how to migrate from using <i>go deps</i> to just using modules? Running <i><b>go mod init</i></b> will use your <i>Gopkg.lock</i> to build your <i>go.mod</i> and <i>go.sum</i> files. Then run <i><b>go mod tidy</i></b> to also collect all of your test dependencies. You can then remove <i>Gopkg.lock</i>, <i>Gopkg.toml</i>, and your old <i>vendor</i> files from the project. Then run <i><b>go get ./…</i></b> and finally, as a sanity check, run <i><b>go test ./…</i></b> to make sure everything still works as expected.

And once again, you can run <i><b>go mod vendor</i></b> in both of these situations to continue supporting those running older versions of Go.


Visit me on [**Twitter**](https://twitter.com/dizdarevicedvin) <3