A Cheatsheet which I hope to reference until memorized.
So I wanted to publish this in attempt to further my own understanding of proper Golang project file structures, especially after writing side projects with varying inflexible and incoherent file structures. I will not in any form claim to understand what I’m talking about, and instead share this as if it were my own notes in attempts to understand why
/pkg is found in every damn project.
Below, I’ve listed commonly found folders if you explored popular Go projects such as:
For a full list, see the Golang Standards Project Layout link below which has a far more extensive listing.
- Contains the
main.go, which is the entrypoint of your application.
- Should be followed directly with your binary name, for example
- Should contain only main execution code, with all logic being imported from
- For application configurations and libraries which you don’t want imported by other applications. NOTE, this is enforced by the compiler as of Go 1.4.
- For sanity, you could extend
/internalto emulate the appropriate file structure (ex.
/internal/pkg) where appropriate.
- Shared library code, which can be imported by both your application and other applications.
- One of the most common layout patterns for bigger applications, for smaller applications this may be considered overkill.
- Manually managed application dependencies (such as environment binaries) are stored here.
- Contains all container (ex.
Dockerfile), packages (
.zip) and scripts into
- CI configurations and scripts get placed in
- Contains both generated documentation via
godocand user design documents.
Final Thoughts and Opinions
Go was written as a server language to be used internally at Google, and I believe it inherited much of it’s semantics from such an environment. We can see this reflected in the project structure with
/internal implying a deep understanding of libraries being shared and used among various services. Furthermore,
/cmd as the entrypoint and with the “least amount of logic” implies the idea further that applications and services are built upon libraries instead of the typical monolithic bits of logic bound to a single project.
Another reason why I wanted to write this was due to following tutorials for various tasks which all had different structural patterns, leading me to submitting constant PRs which changed the overall folder structure without much explanation as to why. Having wrote this small post, I’m already far more confident (and also really apologetic to James and friends who’ve had to deal with my constant Golang “let’s see if we can improve this by rewriting it…..” antics in our projects).
Will I follow this standard in my next Go project? Hopefully.