5 ms·
I don't really understand how this approach would work well with IDEs/autocompletion though. For example, suppose I'm writing some mocked unit tests in Go and
by Arbortheus 4y ago
I don't really understand how this approach would work well with IDEs/autocompletion though.
For example, suppose I'm writing some mocked unit tests in Go and want to use mockgen to generate some mocks on an interface...
//go:generate mockgen (N.B. This generation is done by Bazel)
type Object interface {
Thing() string
}
Then I need to use the generated mocked type in my test:
mockThing := NewMockObject(ctrl)
mockThing.EXPECT().Thing().Return("Foo")
But NewMockObject doesn't exist as far as my IDE knows, because the generated code is only generated at build-time and only exists in the Bazel sandbox.
The code will compile and run successfully, but the developer experience is terrible because you lose the ability to use your IDE's code lens, syntax checks, autocompletion. Everything that's generated shows a red squiggly this-doesnt-exist line.
Maybe I'm just fundamentally misunderstanding how Bazel is supposed to be used. My setup is pretty typical. I develop in VS Code, and build using Bazel, but I do not allow Bazel to automate code generation because the generated sources do not appear in my local environment - just in the bazel sandbox.
Maybe someone can suggest a better approach?
- jen20 4y agoGood IDEs for Java, C# and Rust will handle generated code no problem. I have no idea how VS Code handles this but I’d image it’s a job for the language server. Whether or not Go’s server does it is a different matter - most Go I edit these days is in IntelliJ and built with Bazel, and everything works ok.
- jrockway 4y agoBazel in theory maintains its own directory of generated code that your IDE should refer to. Back when I last used Bazel, there was a bug open to make gopls properly understand this ("go packages driver" is the search term). Nobody touched this bug for a couple years, so I gave up. Here's the bug: https://github.com/bazelbuild/rules_go/issues/512 https://github.com/bazelbuild/rules_go/issues/512 I basically wouldn't use Bazel with Go. Go already has a build system, Bazel is best for languages that don't ship a build system, like C++.
- Arbortheus 4y agoThis is exactly what I needed. However, the tooling around IDEs and the go packages driver still isn't up to scratch. For example, I can't get code lens to use Bazel for testing individual functions. I think I agree that Bazel is poor for Go code, sadly it's what our SREs decided to use for our monorepo.