Should You Commit the Vendor Folder in Go?
If you’re asking “should I commit the vendor folder in my Go project to Git?”, the answer is “almost always”. Let’s talk about why committing is generally better than not.
What is the vendor folder anyways?
If you are coming from Node.js land, Golang’s vendor directory is basically the same as Node’s node_modules. It is a directory found at the root of a Go module that stores a copy of all the code the module depends on. The vendor code is used to compile the final executable when the go build command is run. As you can imagine, at the heart of the “should we commit vendor?” discussion is the problem of repo size.
node_modules is infamous for its large size.

As a result, conventional wisdom in the Node community is to add node_modules to the .gitignore file to save space. After all, a quick npm install (or in Go’s case go get) will pull down all the dependencies everything right?
Yeah. Yeah, it will. Most of the time…
left-pad has entered the chat
npm Err! 404 'left-pad' is not in the npm registry
The error code above famously plagued the developer world because developers were too lazy, or perhaps too sloppy, to write a few simple lines of code. Had a copy of the dependency been committed to all the projects that depended on leftpad, nothing would have been broken when the package was removed from the central NPM servers.
// the entire left-pad library
module.exports = leftpad;
function leftpad(str, len, ch) {
str = String(str);
var i = -1;
if (!ch && ch !== 0) ch = " ";
len = len - str.length;
while (++i < len) {
str = ch + str;
}
return str;
}
Why should Go’s vendor folder be any different than node_modules?
Luckily, up to this point, the Go community has been much more rigorous about using few dependencies. When dependencies are kept to a minimum, it’s easy to commit the entire vendor folder without incurring the huge data cost that the average node_modules folder would demand.
That said, once dependencies get out of control, the only option is to stop committing the folder to source control. If you’re working on a sufficiently large project, it might make sense to you and your team to add vendor to your .gitignore. You’ll just miss out on some amazing benefits of having all the code required to build your app stored in your source control, including:
- Reproducible builds. You never need to worry about missing source code.
- Simple CI/CD. Your CI/CD pipelines don’t need access to remote repos, or permissions to remote private repos to build and test your code.
- Developer friendliness. There isn’t a laundry list of setup instructions you’ll commonly find with Node.js projects. No
npm installrequired.
Final verdict
Just like the flow chart at the beginning of the post outlines, if you don’t have an insane amount of dependencies, just commit those dependencies! Reap the benefits as long as you can. On the other hand, if you do have a metric shitload of external code, maybe you should work on cutting the fat. When dieting isn’t an option due to the size of your codebase, it might be time to remove vendor from your source control.
Related Articles
Learn Go Fast - Top Courses and Resources
Nov 02, 2020 by Lane Wagner - Boot.dev co-founder and backend engineer
Want to learn Go fast? The good news is that Go is one of the simplest programming languages out there. It was designed to have a compact feature set, which means you can learn it much faster than most other languages.
The Nuances of Constants in Go; Go Isn't JavaScript
Oct 22, 2020 by Lane Wagner - Boot.dev co-founder and backend engineer
Constants can be confusing and easy to misuse in Go if you are coming from an untyped language. Let’s take a look at some of the nuanced details of how they work in Go. It’s probably unsurprising, but Go’s constants are almost nothing like JavaScript’s bastardized version of the concept.
How to Structure a Golang Project
Oct 01, 2020 by Lane Wagner - Boot.dev co-founder and backend engineer
I lead a team that’s responsible for anywhere from 15-25 Go microservices at any given time. We’re constantly creating new services and libraries, so it’s become important to streamline the project creation process. I’m mostly writing this article for myself as a kind of self-documentation, but hopefully, you’ll find it useful as you create new Go projects for yourself.
Running Go in the Browser with WASM and Web Workers
Sep 23, 2020 by Lane Wagner - Boot.dev co-founder and backend engineer
We’ve recently made big changes to how we execute Go in the browser on boot.dev and want to explain the enhancements. Web Workers are the reason we’ve been able to solve some of the serious browser-related coding problems that were holding us back. Consider this article a sequel to Running Go in the Browser with Web Assembly.