labstack
Consider making each package its own go module
Currently this project includes way too many dependencies as it is a single module. Making all of them a different module would avoid users to pull dependencies that aren't important for their use case e.g. pulling jaeger and zipkin when willing to use prometheus. Does that make sense?
@jcchavezs - I agree, I was thinking the same. How will someone do a go get on zipkintracing.
@lammel @aldas - Any thoughts? suggestions?
We have had that idea. That JWT lib problem triggered that idea for me personally. At the moment we do not have clear plan how and when it should be done (probably with v5). Anyway I support the idea.
one note here. as a maintainer it quite inconvenient to track many repos and their issues/PRs. The amount of questions/false-positives is quite high. Sometimes github does not send even notifications so I find existance of some PR only if I specially check that repository PR tab.
I wonder if monorepo for middlewares with each middleware split into different modules with their own go.mod go.sum files would work with go mod.
I wonder if monorepo for middlewares with each middleware split into different modules with their own go.mod go.sum files would work with go mod.
It works as long as no circular dependencies or ideally no dependencies between them otherwise it will be a nightmare.
We have had that idea. That JWT lib problem triggered that idea for me personally. At the moment we do not have clear plan how and when it should be done (probably with v5). Anyway I support the idea.
I think (99% sure) introducing go modules won't be a breaking change as people will still call packages in the same way, the only difference will be how the dependencies are resolved so I think no need to wait for v5.
I wonder if monorepo for middlewares with each middleware split into different modules with their own go.mod go.sum files would work with go mod.
replying to myself: semantic versioning of each MW would not be possible probably in this setup.
replying to myself: semantic versioning of each MW would not be possible probably in this setup.
Not really but that is IMHO a goal which is not worth. Semantic versioning of each MW opens up the box for a huge compatibility matrix which you might not like to deal with. I'd just release them all together.
Go 1.17 has some nice features
if the main module specifies go 1.17 or higher the go tool no longer reads (or even downloads) go.mod files for dependencies if they are not needed in order to complete the requested command. (See Lazy loading.)
I have not tried it yet but seems that from 1.17 dependencies you are not using are not downloaded anymore.
That would be awesome and would allow keeping it all together here with simpler versioning. Need to take a look and give it a try.
