golang standard project layout

(there is no such thing)

[...]
But for the record, the minimal standard layout for an importable Go repo is really:
Put a LICENSE file in your root
Put a go.mod file in your root
Put Go code in your repo, in the root or organized into a directory tree as you see fit
That's it. That's the "standard".
[...]
- rsc
			

How to structure your go project

There is no official go standard project layout. For tips on how to structure your go project check the following links.

What about github.com/golang-standards/project-layout?

Despite the name this is neither a standard nor endorsed by the golang team. The layout presented in the repo is too complex for most projects and having "standard" in the name is confusing the go newcomers. this is not a standard Go project layout #117 - github issue
The README makes clear that this is not official, but even the claim "it is a set of common historical and emerging project layout patterns in the Go ecosystem" is not accurate.

For example, the vast majority of packages in the Go ecosystem do not put the importable packages in a pkg subdirectory. More generally what is described here is just very complex, and Go repos tend to be much simpler.

It is unfortunate that this is being put forth as "golang-standards" when it really is not. I'm commenting here because I am starting to see people say things like "you are not using the standard Go project layout" and linking to this repo.
- rsc
There are two problems with this GitHub repo:

it claims to host Go standards and does not, in the sense that these are in no way official standards
the project-layout standard it puts forth is far too complex and not a standard
Regarding "why not tell us the standard Go project layout and we'll update the doc?", that only addresses point 2. If there really were standards, they would be in the main Go project doc tree. The standard for project layout would also be a lot shorter. I appreciate your trying to provide a useful resource, but calling it 'golang-standards' is claiming more than it is.

But for the record, the minimal standard layout for an importable Go repo is really:

Put a LICENSE file in your root
Put a go.mod file in your root
Put Go code in your repo, in the root or organized into a directory tree as you see fit
That's it. That's the "standard".

In particular:

It is not required to put commands in cmd/.
It is not required to put packages in pkg/.
It is not required to put web stuff in web/.
It is not required to put APIs in api/.
It is not required to put web stuff in web/.
It is not required to put configurations in configs/.
It is not required to put systemd scripts in init/.
It is not required to put shell scripts in scripts/.
It is not required to put Docker files in build/package/.
It is not required to put CI configs in build/ci/.
It is not required to put deployment configs in deployments/.
It is not required to put test support in test/.
It is not required to put documentation in docs/.
It is not required to put supporting tools in tools/.
It is not required to put examples in examples/.
It is not required to put third_party code in third_party/.
It is not required to put git hooks in githooks/
It is not required to put static assets in assets/.
It is not required to put website data in website/.

The importable golang.org/x repos break every one of these "rules".
- rsc
this is not a standard Go project layout #117 - discussion of the issue on reddit.com/r/golang Rename the organization #52 - github issue
The name organization name golang-standards is misleading for beginners and people new to Go. It implies that the included repositories - which are misleading as well, btw - conclude official standards, which is definitly not the case.
This repository has multiple serious issues #41 - github issue
The existence of this repository is harmful for Go beginners. People arrive here from Google searches, looking for ways to structure their small, simple packages. What they find is overwhelming, at the least.

It has several serious issues:

No go.mod file, while modules are becoming a standard for Go dependency management
Suggests to place all exportable code in pkg/, which is outdated advice and no longer recommended for Go projects (as it adds a superfluous path component to every import).
Has a large number of directories, most of which aren't needed by 99% of projects
Please either spend some time to modernize this project, or delete it
		
Delete this repo #36 - github issue
Please, delete this repo, because it brings nothing else but confusion and encourages bad practices in go (a lot around naming) especially for beginners.

Especially it's bad when new go developers start to advocate bad practices and use this repo as a reference.

Instead, create a list of resources that would bring knowledge about the "industry standards" (the way how go is written in stdlib)

Like those:

0. Go basics
https://tour.golang.org/welcome/1
https://gobyexample.com/
https://blog.golang.org/context
https://ekocaman.com/go-context-c44d681da2e8

Would highly recommend to read this even if you’re advanced Gopher - http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/

1. Style guideline for Go packages
https://rakyll.org/style-packages/

One of the famous figures and main contributors to Go language, Rakyll, writes about importance of naming and structuring of the packages.

2. Effective Go
https://golang.org/doc/effective_go.html

Effective Go article is a community evangel of how effective Go code should be written.

3. Code Review Comments
https://github.com/golang/go/wiki/CodeReviewComments

Wiki page from Go repository with idiomatic code habits that would help you to avoid traps of trying to write Java (or C#, or TypeScript, or Javascript) in Go which never works.

4. Structuring applications for Growth in Go
https://www.youtube.com/watch?v=LMSbsW1Xpwg
In this lightning talk, Ben Johnson gives a quick idea of what kind of issues you might face with inappropriate project structure

5. Best Practices for Industrial Programming
https://www.youtube.com/watch?v=PTE4VJIdHPg
Peter Bourgon dives deeper into the ways of setting up the project structure that are more adopted within the industry, providing also more justifications on an issues that he was facing on his Go journey. A lot of his practices are widely used within the Go community.