[konart]

>What I would really like is an up to date "learn how to handle Go project in 30 minutes"

1. git init

2. git remote add %something%

3. go mod init %name_of_your_module% (where in most common case name is your repo address without the https part)

4. https://github.com/golang-standards/project-layout - this repo has the default project structure. Each subfolder has README that describes the purpose of the folder

5. go get -u github.com/gin-gonic/gin to add gin (web lib) for your project. Same for any other package. The will be added to your go.mod and go.sum files

5.1 import "github.com/gin-gonic/gin" in your code to use gin

5.2 package may have more than one major version (tag). If you want to use package at latest tag 2 - you add '/v2' when you 'go get' the package (i.e. go get -u github.com/gin-gonic/gin/v2)

6. git commit && git push to publish

7. Not sure what to you mean by 'fork&clone&submit&pr including 3rd party submodules'. You may use vendoring but in most cases you don't need it as you have your dependencies in your go.mod && go.sum files. You may want to read more about vendoring and gomodproxy though.

8. Testing is pretty easy but I guess you want and article about best practices? I won't post any link as I find the topic as too controversial regardless of the language\stack

9. CI - not sure that does this have to do with the language

10. haven't done much profiling or debugging to fill you in.

[hactually]

Damn.

> https://github.com/golang-standards/project-layout

I was almost with you but please don't share that repo. It's a terrible layout and the docs aren't accurate. The issues are full of Go community folk saying it's misleading and looks official but isn't.

[konart]

It is not official and does not say otherwise (neither do I).

We are using similar layout (albeit we just need cmd and internal directories for most of our project) and it works perfectly.

Anyway - this is not Rails or any other framework were the developer may be dependent on project structure. I just shared a possible option.

>It's a terrible

Why though?

PS: I just realized it has golang-standards in its path. Okay, this part can actually be misleading.

[phernandez]

I have had this issue with my current golang projects. I haven't found any clear standard for project layout. We have a bunch of microservices with grpc api endpoints, and some which are event driven. Has anyone found a better resource? As it is, even our internal projects are fairly inconsistent in their project structure, which is a bit annoying.

[konart]

There is no such thing as a standard here.

In our team we have most projects structured like this:

/project-folder

|

|__/build (/.gitlab-ci for projects moved to our own gitlab instance)

|

|__/cmd (folder for your entrypoints. One or more if your projects generates more than 1 binary)

   |__/bin_name1

   |__/bin_name2

|

|__/internal (folder for your sources packages)

   |__/config (package config)

   |__/http (package HTTPServer, api, etc)

      |__/api

      |__/models

   |__/database (package database)

   |__...

|

|__/api (swagger and such)

|

|__/docs (godoc)

|

|__/.golangci.yml

|

|__...

Something like this.

[dpc_pw]

> Not sure what to you mean by 'fork&clone&submit&pr including 3rd party submodules'.

Sometimes a 3rd party library needs a fix, and you want to fork it, add your changes, and run with it like that until your changes land in the upstream.

Last time I had to deal with it was a PITA, because libraries were fully qualified, and now I wanted to make an override. In Rust I would use https://doc.rust-lang.org/cargo/reference/overriding-depende...

[konart]

Oh! I get in now.

In Go you can 'replace' a required package.

https://thewebivore.com/using-replace-in-go-mod-to-point-to-...

You can replace with local or remote package (for example if you have published fixed version somewhere and what your teammates to use it too until your changes land in the upstream.)