When using Bazel to build a project that contains .proto files, we can use, for example, go_binary and go_proto_library rules to create a binary. The generated binary will work as expected, but the code generated from the .proto files is not in the working directory.
As a result, code completion in editors and IDEs will not work. Even worse, they will often print errors about invalid import statements.
This is an example using protocol buffers, but there are probably other similar cases, such as using third party dependencies.
How is this usually handled?
I'm one of the engineers working on the Go rules for Bazel. Unfortunately, I don't have a good answer for you right now, but this issue is on our radar, and the Go team is working on a general long-term solution. I've filed bazelbuild/rules_go#512 on our GitHub repo to track this issue, and I'll update this answer when we have a better solution.
The problem is Bazel stores generated code and other artifacts in its own internal directory that editors aren't aware of. We're designing and building a new workspace abstraction mechanism that will allow tools (editors, IDEs, tools like guru) to understand all of sources, generated files, packages, imports, and other metadata in a repository without needing to integrate directly with Bazel or other build systems.
As a temporary workaround, try generating the .pb.go files manually with protoc. You can check those files into your repository but not include them in your BUILD files. This should make editors and IDEs aware of the generated files, but you'll still produce new, up-to-date versions of them when you compile.
I ran into the same issue with Buck too, and implemented a workaround to have Buck copying generated code to vendor folder.
Looking forward to the workspace abstraction mechanism in Go though.