4 ms·

Official guide for organizing Go projects and modules

83 points by dondraper36 3y ago

dondraper36 3y ago
Finally, there is an official document with recommended ways to structure your Go project. To be honest, it's really minimal and liberal but that is definitely better than what is by an unfortunate name collision considered the official Go layout now.
- biomcgary 3y ago
  I'm so glad to finally see this! Thanks for posting it. In the absence of this, the name-squatting package you reference has exploited the confusion for the author's benefit, while providing sup-optimal advice to Go newbies.
- Cthulhu_ 3y ago
  Minimal and liberal is a good thing, it resonates with the greater Go mindset imo; that said, if I were to add anything, it's maybe link people to architecture ideas like Clean Architecture, which is often recommended in the community to structure larger projects.
js2 3y ago
Questions left unanswered: - When are go multi-module workspaces best used? - What should you use for the module-path argument to `go mod init` if you don't ever intend to share the repo or you don't yet know where you will be sharing it?
- arp242 3y ago
  1. When it's more convenient than not using them. 2. Anything is fine: just a name ("myproject"), a fake URL, a real URL. Whatever works for you. This may seem overly simplistic and I'm not trying to be dismissive, but that's really what it comes down to. Sometimes things really are just simple. I don't understand the desire to "standardize" and "document" everything to the microscopic detail.
- pjmlp 3y ago
  Another one, - How to handle binary modules?
  - domust 3y ago
    Just don't: https://github.com/golang/go/issues/28146 https://github.com/golang/go/issues/28146
    - pjmlp 3y ago
      I know, yet another thing that makes Go unusable for typical corporations.
      - Cthulhu_ 3y ago
        How come said typical corporations need binary modules? Those aren't very portable, and make maintenance long term a lot more complicated.
mmcallister 3y ago
Compare and contrast this with the Go Standards project-layout repo example[1] - which ironically is not a standard at all. Personally I prefer a bit more rigidity in how the project is structured (/pkg/, /pkg/internal/, /cmd/) since it is more opinionated and requires less thinking. Typically my repos won't just have a Go backend but also a frontend too, and supporting assets, as well as documentation (designs, decisions, etc.) [1] https://github.com/golang-standards/project-layout https://github.com/golang-standards/project-layout
burgerrito 3y ago
Is this a new page? Don't remember if I've read this one or not.
Zababa 3y ago
I knew it reminded me of something! Eli Bendersky's post https://eli.thegreenplace.net/2019/simple-go-project-layout-with-modules/ https://eli.thegreenplace.net/2019/simple-go-project-layout-... now starts with "Update (2023-09-19): We've now published similar guidelines as part of Go's official documentation. This blog post will remain up-to-date." I've learned a lot about Go from this website.

83 points by dondraper36 3y ago

Finally, there is an official document with recommended ways to structure your Go project. To be honest, it's really minimal and liberal but that is definitely better than what is by an unfortunate name collision considered the official Go layout now.

biomcgary 3y ago
I'm so glad to finally see this! Thanks for posting it. In the absence of this, the name-squatting package you reference has exploited the confusion for the author's benefit, while providing sup-optimal advice to Go newbies.
Cthulhu_ 3y ago
Minimal and liberal is a good thing, it resonates with the greater Go mindset imo; that said, if I were to add anything, it's maybe link people to architecture ideas like Clean Architecture, which is often recommended in the community to structure larger projects.

js2 3y ago

Questions left unanswered: - When are go multi-module workspaces best used? - What should you use for the module-path argument to `go mod init` if you don't ever intend to share the repo or you don't yet know where you will be sharing it?

arp242 3y ago
1. When it's more convenient than not using them. 2. Anything is fine: just a name ("myproject"), a fake URL, a real URL. Whatever works for you. This may seem overly simplistic and I'm not trying to be dismissive, but that's really what it comes down to. Sometimes things really are just simple. I don't understand the desire to "standardize" and "document" everything to the microscopic detail.
pjmlp 3y ago
Another one, - How to handle binary modules?
- domust 3y ago
  Just don't: https://github.com/golang/go/issues/28146 https://github.com/golang/go/issues/28146
  - pjmlp 3y ago
    I know, yet another thing that makes Go unusable for typical corporations.
    - Cthulhu_ 3y ago
      How come said typical corporations need binary modules? Those aren't very portable, and make maintenance long term a lot more complicated.

mmcallister 3y ago

Compare and contrast this with the Go Standards project-layout repo example[1] - which ironically is not a standard at all. Personally I prefer a bit more rigidity in how the project is structured (/pkg/, /pkg/internal/, /cmd/) since it is more opinionated and requires less thinking. Typically my repos won't just have a Go backend but also a frontend too, and supporting assets, as well as documentation (designs, decisions, etc.) [1] https://github.com/golang-standards/project-layout https://github.com/golang-standards/project-layout

burgerrito 3y ago

Is this a new page? Don't remember if I've read this one or not.

Zababa 3y ago

I knew it reminded me of something! Eli Bendersky's post https://eli.thegreenplace.net/2019/simple-go-project-layout-with-modules/ https://eli.thegreenplace.net/2019/simple-go-project-layout-... now starts with "Update (2023-09-19): We've now published similar guidelines as part of Go's official documentation. This blog post will remain up-to-date." I've learned a lot about Go from this website.