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.
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.
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.
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:
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/2fb0b4985893e3397...