5 ms·

Show HN: Monogo – Evolve your go workspace to a real monorepo

35 points by elmazout 2y ago

Hi there, I've been working sporadically over the last six months on a go monorepo tool (0 config it just use go workspace and go convention). It’s basically like TurboRepo but without the task runner. The tool builds a dependency graph between packages, allowing you to do things similar to what you can do in TurboRepo, like "only test the packages and the packages that depend on them, compared to the main branch," or "only install dependencies for Package A and its dependencies," etc. I use native go tool to get dependencies and create dependency graph between the package.Nothing crazy but I feel it could be useful.

deleted 2y ago
[deleted]
hahn-kev 2y ago
If this is not related to Mongo Db why is the name so similar?
- ithkuil 2y ago
  Because "mono" (repo) + "go" (the language)
  - elmazout 2y ago
    Right, the name is so bad, but if someone else have a better idea, I'm open.
    - ithkuil 2y ago
      Monogolar ?
TheDong 2y ago
It's surprising the go tooling doesn't have a more native way to do something like this already. Upstream issue: https://github.com/golang/go/issues/50745 https://github.com/golang/go/issues/50745 Like, go already has test caching (so "only test stuff that changed" shouldn't be necessary, that should just happen), and code formatting and such is already quite fast... Overall, I feel like having another tool which parses my go source code is going to be slower than writing a Makefile to wrap: go list -f '{{.Dir}}' -m | xargs -L1 go test ./... which is all this tool doing really. Also, hilariously, the repo isn't go fmt'd [0], despite being a tool to go fmt your repo. That's really funny, but I don't think the go community is ready for that level of humor yet, maybe one day. [0]: https://github.com/nicolasgere/monogo/blob/2fb0b4985893e3397df86bdee0d4ea728db506ab/lib/analyser/parse.go#L78 https://github.com/nicolasgere/monogo/blob/2fb0b4985893e3397...
- fragmede 2y ago
  blaze and bazel are why there's not a whole lot of upstream work dedicated to this issue
  - elmazout 2y ago
    True, but they are so much complex (and much more powerful). This is more an equivalent to turborepo, minimal config and integrate directly with the language.
- bheadmaster 2y ago
  > That's really funny, but I don't think the go community is ready for that level of humor yet, maybe one day. I am a Gopher, and ironically, I didn't quite understand what this means. Would you care to elaborate?
  - croshan 2y ago
    Go bootstraps itself (Go is compiled by Go) but Gofmt does not format itself (an even simpler job).
- elmazout 2y ago
  I agree, it can be done with a makefile, just except the dependency based runner, if you have module A depending on B, you want to test A and B, this is what a tool like bazel would solve, as well as monogo.

35 points by elmazout 2y ago

deleted 2y ago

[deleted]

hahn-kev 2y ago

If this is not related to Mongo Db why is the name so similar?

ithkuil 2y ago
Because "mono" (repo) + "go" (the language)
- elmazout 2y ago
  Right, the name is so bad, but if someone else have a better idea, I'm open.
  - ithkuil 2y ago
    Monogolar ?

TheDong 2y ago

It's surprising the go tooling doesn't have a more native way to do something like this already. Upstream issue: https://github.com/golang/go/issues/50745 https://github.com/golang/go/issues/50745 Like, go already has test caching (so "only test stuff that changed" shouldn't be necessary, that should just happen), and code formatting and such is already quite fast... Overall, I feel like having another tool which parses my go source code is going to be slower than writing a Makefile to wrap: go list -f '{{.Dir}}' -m | xargs -L1 go test ./... which is all this tool doing really. Also, hilariously, the repo isn't go fmt'd [0], despite being a tool to go fmt your repo. That's really funny, but I don't think the go community is ready for that level of humor yet, maybe one day. [0]: https://github.com/nicolasgere/monogo/blob/2fb0b4985893e3397df86bdee0d4ea728db506ab/lib/analyser/parse.go#L78 https://github.com/nicolasgere/monogo/blob/2fb0b4985893e3397...

fragmede 2y ago
blaze and bazel are why there's not a whole lot of upstream work dedicated to this issue
- elmazout 2y ago
  True, but they are so much complex (and much more powerful). This is more an equivalent to turborepo, minimal config and integrate directly with the language.
bheadmaster 2y ago
> That's really funny, but I don't think the go community is ready for that level of humor yet, maybe one day. I am a Gopher, and ironically, I didn't quite understand what this means. Would you care to elaborate?
- croshan 2y ago
  Go bootstraps itself (Go is compiled by Go) but Gofmt does not format itself (an even simpler job).
elmazout 2y ago
I agree, it can be done with a makefile, just except the dependency based runner, if you have module A depending on B, you want to test A and B, this is what a tool like bazel would solve, as well as monogo.