Standard Go Project Layout

Overview

Standard Go Project Layout

Translations:

Overview

This is a basic layout for Go application projects. It's not an official standard defined by the core Go dev team; however, it is a set of common historical and emerging project layout patterns in the Go ecosystem. Some of these patterns are more popular than others. It also has a number of small enhancements along with several supporting directories common to any large enough real world application.

If you are trying to learn Go or if you are building a PoC or a toy project for yourself this project layout is an overkill. Start with something really simple (a single main.go file is more than enough). As your project grows keep in mind that it'll be important to make sure your code is well structured otherwise you'll end up with a messy code with lots of hidden dependencies and global state. When you have more people working on the project you'll need even more structure. That's when it's important to introduce a common way to manage packages/libraries. When you have an open source project or when you know other projects import the code from your project repository that's when it's important to have private (aka internal) packages and code. Clone the repository, keep what you need and delete everything else! Just because it's there it doesn't mean you have to use it all. None of these patterns are used in every single project. Even the vendor pattern is not universal.

With Go 1.14 Go Modules are finally ready for production. Use Go Modules unless you have a specific reason not to use them and if you do then you don’t need to worry about $GOPATH and where you put your project. The basic go.mod file in the repo assumes your project is hosted on GitHub, but it's not a requirement. The module path can be anything though the first module path component should have a dot in its name (the current version of Go doesn't enforce it anymore, but if you are using slightly older versions don't be surprised if your builds fail without it). See Issues 37554 and 32819 if you want to know more about it.

This project layout is intentionally generic and it doesn't try to impose a specific Go package structure.

This is a community effort. Open an issue if you see a new pattern or if you think one of the existing patterns needs to be updated.

If you need help with naming, formatting and style start by running gofmt and golint. Also make sure to read these Go code style guidelines and recommendations:

See Go Project Layout for additional background information.

More about naming and organizing packages as well as other code structure recommendations:

A Chinese Post about Package-Oriented-Design guidelines and Architecture layer

Go Directories

/cmd

Main applications for this project.

The directory name for each application should match the name of the executable you want to have (e.g., /cmd/myapp).

Don't put a lot of code in the application directory. If you think the code can be imported and used in other projects, then it should live in the /pkg directory. If the code is not reusable or if you don't want others to reuse it, put that code in the /internal directory. You'll be surprised what others will do, so be explicit about your intentions!

It's common to have a small main function that imports and invokes the code from the /internal and /pkg directories and nothing else.

See the /cmd directory for examples.

/internal

Private application and library code. This is the code you don't want others importing in their applications or libraries. Note that this layout pattern is enforced by the Go compiler itself. See the Go 1.4 release notes for more details. Note that you are not limited to the top level internal directory. You can have more than one internal directory at any level of your project tree.

You can optionally add a bit of extra structure to your internal packages to separate your shared and non-shared internal code. It's not required (especially for smaller projects), but it's nice to have visual clues showing the intended package use. Your actual application code can go in the /internal/app directory (e.g., /internal/app/myapp) and the code shared by those apps in the /internal/pkg directory (e.g., /internal/pkg/myprivlib).

/pkg

Library code that's ok to use by external applications (e.g., /pkg/mypubliclib). Other projects will import these libraries expecting them to work, so think twice before you put something here :-) Note that the internal directory is a better way to ensure your private packages are not importable because it's enforced by Go. The /pkg directory is still a good way to explicitly communicate that the code in that directory is safe for use by others. The I'll take pkg over internal blog post by Travis Jeffery provides a good overview of the pkg and internal directories and when it might make sense to use them.

It's also a way to group Go code in one place when your root directory contains lots of non-Go components and directories making it easier to run various Go tools (as mentioned in these talks: Best Practices for Industrial Programming from GopherCon EU 2018, GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps and GoLab 2018 - Massimiliano Pippi - Project layout patterns in Go).

See the /pkg directory if you want to see which popular Go repos use this project layout pattern. This is a common layout pattern, but it's not universally accepted and some in the Go community don't recommend it.

It's ok not to use it if your app project is really small and where an extra level of nesting doesn't add much value (unless you really want to :-)). Think about it when it's getting big enough and your root directory gets pretty busy (especially if you have a lot of non-Go app components).

/vendor

Application dependencies (managed manually or by your favorite dependency management tool like the new built-in Go Modules feature). The go mod vendor command will create the /vendor directory for you. Note that you might need to add the -mod=vendor flag to your go build command if you are not using Go 1.14 where it's on by default.

Don't commit your application dependencies if you are building a library.

Note that since 1.13 Go also enabled the module proxy feature (using https://proxy.golang.org as their module proxy server by default). Read more about it here to see if it fits all of your requirements and constraints. If it does, then you won't need the vendor directory at all.

Service Application Directories

/api

OpenAPI/Swagger specs, JSON schema files, protocol definition files.

See the /api directory for examples.

Web Application Directories

/web

Web application specific components: static web assets, server side templates and SPAs.

Common Application Directories

/configs

Configuration file templates or default configs.

Put your confd or consul-template template files here.

/init

System init (systemd, upstart, sysv) and process manager/supervisor (runit, supervisord) configs.

/scripts

Scripts to perform various build, install, analysis, etc operations.

These scripts keep the root level Makefile small and simple (e.g., https://github.com/hashicorp/terraform/blob/master/Makefile).

See the /scripts directory for examples.

/build

Packaging and Continuous Integration.

Put your cloud (AMI), container (Docker), OS (deb, rpm, pkg) package configurations and scripts in the /build/package directory.

Put your CI (travis, circle, drone) configurations and scripts in the /build/ci directory. Note that some of the CI tools (e.g., Travis CI) are very picky about the location of their config files. Try putting the config files in the /build/ci directory linking them to the location where the CI tools expect them (when possible).

/deployments

IaaS, PaaS, system and container orchestration deployment configurations and templates (docker-compose, kubernetes/helm, mesos, terraform, bosh). Note that in some repos (especially apps deployed with kubernetes) this directory is called /deploy.

/test

Additional external test apps and test data. Feel free to structure the /test directory anyway you want. For bigger projects it makes sense to have a data subdirectory. For example, you can have /test/data or /test/testdata if you need Go to ignore what's in that directory. Note that Go will also ignore directories or files that begin with "." or "_", so you have more flexibility in terms of how you name your test data directory.

See the /test directory for examples.

Other Directories

/docs

Design and user documents (in addition to your godoc generated documentation).

See the /docs directory for examples.

/tools

Supporting tools for this project. Note that these tools can import code from the /pkg and /internal directories.

See the /tools directory for examples.

/examples

Examples for your applications and/or public libraries.

See the /examples directory for examples.

/third_party

External helper tools, forked code and other 3rd party utilities (e.g., Swagger UI).

/githooks

Git hooks.

/assets

Other assets to go along with your repository (images, logos, etc).

/website

This is the place to put your project's website data if you are not using GitHub pages.

See the /website directory for examples.

Directories You Shouldn't Have

/src

Some Go projects do have a src folder, but it usually happens when the devs came from the Java world where it's a common pattern. If you can help yourself try not to adopt this Java pattern. You really don't want your Go code or Go projects to look like Java :-)

Don't confuse the project level /src directory with the /src directory Go uses for its workspaces as described in How to Write Go Code. The $GOPATH environment variable points to your (current) workspace (by default it points to $HOME/go on non-windows systems). This workspace includes the top level /pkg, /bin and /src directories. Your actual project ends up being a sub-directory under /src, so if you have the /src directory in your project the project path will look like this: /some/path/to/workspace/src/your_project/src/your_code.go. Note that with Go 1.11 it's possible to have your project outside of your GOPATH, but it still doesn't mean it's a good idea to use this layout pattern.

Badges

  • Go Report Card - It will scan your code with gofmt, go vet, gocyclo, golint, ineffassign, license and misspell. Replace github.com/golang-standards/project-layout with your project reference.

    Go Report Card

  • GoDoc - It will provide online version of your GoDoc generated documentation. Change the link to point to your project.

    Go Doc

  • Pkg.go.dev - Pkg.go.dev is a new destination for Go discovery & docs. You can create a badge using the badge generation tool.

    PkgGoDev

  • Release - It will show the latest release number for your project. Change the github link to point to your project.

    Release

Notes

A more opinionated project template with sample/reusable configs, scripts and code is a WIP.

Issues
  • Missing simple approach to building and vendoring

    Missing simple approach to building and vendoring

    Pulling out my hair to do something as simple (or in go- complex) as using dep, gb and make to perform a simple build of a repo with this structure. Even if its opinionated it would help to show

    • a Makefile including gb (the refs are good but much too complex for a beginner)
    • a way to use dep for installing dependencies as part of the make process
    opened by andig 10
  • Using docker while every service in cmd directory is another image

    Using docker while every service in cmd directory is another image

    Hello, I'm struggling with building each /cmd/* separately, not as a single image, and I'm not able to build it when context directory doesn't have go.mod itself. Have anyone managed to use Docker with this layout?

    opened by gbaranski 6
  • Not clear where to put files containing secrets

    Not clear where to put files containing secrets

    I've a service account file generated by Google which contains (secret) keys. I can't conclude from the current setup where to put these into.

    My first idea was configs. But for me, configs can be public.

    opened by ndabAP 6
  • Dockerfile for standard project layout

    Dockerfile for standard project layout

    Does anyone have sample of dockerfile for standard project layout for the multi stage build ?

    please help

    opened by dunods 5
  • Add readme chinese translation

    Add readme chinese translation

    Add readme chinese translation.

    https://github.com/golang-standards/project-layout/issues/66

    opened by Promacanthus 3
  • add README_zh.md

    add README_zh.md

    I translated the Chinese document, hoping to help some developers from China to read this document friendly.

    opened by kscooo 3
  • Where do you keep certificate files?

    Where do you keep certificate files?

    It's not clear where the *.crt files go. Please help.

    opened by thesobercoder 3
  • Add Russian Translation

    Add Russian Translation

    Hi everyone! I`ve done translating README to Russian, how can I create a merge request or something?

    opened by Qussth 3
  • Add Japanese translation

    Add Japanese translation

    opened by GunjiKamiya 2
  • Config example directory

    Config example directory

    Where should I put config example for a cmd according to this layout? "assets" directory?

    opened by edwvee 0
  • missing v2 folder

    missing v2 folder

    For repositories that provide libraries that are imported into other projects, if it needs to support multiple major versions at the same time (which is common) then the idiomatic go approach is to create a v2 folder to put it in (with its own go.mod and go.sum)

    This should be referenced somewhere - possibly in the /pkg folder? or possibly by adding a /v2 folder to the root - as both are valid I think

    see: https://go.dev/blog/v2-go-modules#TOC_2

    opened by c-mcallister 0
  • Broken link

    Broken link

    The cmd/README.md have broken link: https://github.com/satellity/satellity/tree/master/cmd/satellity

    opened by v-dudnikov 0
  • Use a more standard language mark

    Use a more standard language mark

    • re-update the multilingual navigation at the beginning of each readme file (The content of the file other than navigation is not changed. If there is a difference, it may be caused by formatting the file.)

    (#130)

    opened by misitebao 0
  • Multi-language support

    Multi-language support

    Regarding multi-language related PR can be linked to this issue.

    opened by misitebao 0
  • What

    What "hacker license" means ?

    I could not understand "hacker license" in License.md and I could not find the license's body. Please describe more details of the license.

    opened by dote-tomo-mic 1
  • plz clear

    plz clear "standards",lt is not standards.so “Funny”!

    plz clear "standards",lt is not standards.so “Funny”! plz clear "standards",lt is not standards.so “Funny”! plz clear "standards",lt is not standards.so “Funny”!

    opened by AnkoGo 0
  • Update pkg directory description

    Update pkg directory description

    Russ created #117, so let's discuss for week in a row, how bad pkg dir for newb...

    Oh, wait, i fixed it! Opensource time!

    Is it REALLY so fucking difficult to propose goddamn layout change?
    opened by quenbyako 1
  • #117 must be closed and locked

    #117 must be closed and locked

    I think I will take responsibility for this issue and propose to close #117, as it became as unhealthy cancelling and persecution of people who disagree with the author.

    In order not to be unfounded, I will try to express as neutral as possible all the pros and cons of this decision:

    pros:

    • this repository mimics to golang officially standards, however golang has not any standards for the architecture of the code (which is a lie, since much parts of this repository is generally accepted in community)
    • repository name confuses newbies trying to apply knowledge from django, rust, flutter, etc to go (which has not been proven by any contributor, even @rsc)
    • layout is bloated, which is actually true
    • layout tries to be universal to any go project
    • readme warranty doesn't look helpful
    • layout pretends that it is the only true layout in the world (which is even a big lie)
    • at this moment only two guys thumbs down 117 issue, "everyone" agree with Russ

    cons:

    • THIS IS THE MOST IMPORTANT: the discussion spills out from slack and github, and I noticed at least 4 chats in telegram, and one discord server insults the participants because they disagree with @rsc. Unlike YouTube, github has a list of the first 6 people who responded to a post, so members are just afraid to put their thumbs down. such behavior is unacceptable not only in the go community, but in any other.
    • term "standard" does not mean an officially accepted document, even the Cambridge Dictionary defines a 'standard' primarily as a pattern or model that is generally accepted, accepted in our community.
    • the statement that the README warranty is not obvious is simply stupid: the READ_ME is created in order to read it before using the software. Those people who agree with this argument mostly agree that the readme should be refactored in order to improve the understanding by golang newbies the purpose of this repository.
    • To demand from the author in an ultimatum form to rename the repository is at best uncivilized, at worst it is pure persecution. if this project bothers you, scold those who impose it on you, not the authors of the project.
    • at the moment this is the most popular project, and instead of renaming it would be more logical to call @rsc @rakyll @spf13 @avelino @muesli @valyala ~~(me? jk)~~ and other famous faces of golang community and discuss how this project can be improved. This layout is important for the community, despite the fact that it is not of the highest quality. Agree with it or not, there are lots of people who see this repo useful.

    At the same time, I would want to remind you about the story with @kataras who does not accept criticism at all (still not, yeah). Now an identical situation is became right here, but in the different direction: now people are starting to hound the author who didn't anything bad, and they also hound people who disagree with @rsc's position. and all this holywar for the sake of the "concerns they are raising"


    I would also want to remind you that it is more logical to offer alternatives if you do not agree with someone's opinion. In №117 i already made this list of alternative best practices, but I will copy it here too, maybe it will help someone:

    Most good articles from @henvic:

    • https://golang.org/doc/effective_go
    • https://github.com/golang/go/wiki/CodeReviewComments
    • https://github.com/golang/go/wiki
    • https://golang.org/ref/spec

    @flowchartsman share these pretty useful posts:

    • https://eli.thegreenplace.net/2019/simple-go-project-layout-with-modules/
    • https://blog.golang.org/organizing-go-code
    • https://rakyll.org/style-packages/
    • https://peter.bourgon.org/go-best-practices-2016/#repository-structure

    @xhit was the first who wrote good argument about standard layout of stdlib (which is well organized btw):

    • https://github.com/golang/go/tree/master/src

    @higker noted this go blog post:

    • https://blog.golang.org/package-names

    @xxbtwxx shared amazingly bad structured repo (read as: "how not to layout your code, and why use this is really bad"):

    • https://github.com/Shopify/sarama (too funny and too sad lib at the same time, unfortunately)

    @itsjamie shared this post:

    • https://christine.website/blog/within-go-repo-layout-2020-09-07

    So #117 must be stopped. For community health.

    opened by quenbyako 8
  • fix typo and markdown style

    fix typo and markdown style

    opened by junjieyuan 2
Go Project Sample Layout

go-sample A sample layout for Go application projects with the real code. Where it all comes from? Ideas used to create the architecture and structure

Eugene Russkikh 92 Sep 10, 2021
Generate scaffold project layout for Go.

scaffold Scaffold generates starter Go project layout. Let you can focus on buesiness logic implemeted. The following is Go project layout scaffold ge

CATCHPLAY 100 Sep 11, 2021
Go Todo Backend example using modular project layout for product microservice.

go-todo-backend Go Todo Backend Example Using Modular Project Layout for Product Microservice. It's suitable as starting point for a medium to larger

Muhammad Surya 100 Sep 23, 2021
Modern Go Application example

Modern Go Application Go application boilerplate and example applying modern practices This repository tries to collect the best practices of applicat

Márk Sági-Kazár 1.1k Sep 25, 2021
Nwg-drawer is a golang replacement to the nwggrid command (a part of nwg-launchers).

Nwg-drawer is a golang replacement to the nwggrid command (a part of nwg-launchers). It's being developed with sway in mind, but should also work with other wlroots-based Wayland compositors. X Window System is not supported.

Piotr Miller 25 Sep 21, 2021
Epitech BSQ in Golang

EPITECH BSQ in Golang BSQ GO What is BSQ ? The goal of the project is to find the biggest square on a map while avoiding obstacles. The file map is pa

XriM 3 Sep 14, 2021