Skip to main content
Output files from Bazel spawns are always written beneath the bazel-out tree. But other tools allow, or even expect, that files are present in the source tree. This is frequently observed with Editors and IDEs for example. We can un-break the situation if we relax the Bazel dogma around writing to the source tree. For example, in the logger/schema folder we should have a ts_proto_library target which produces a logger_pb.d.ts interface definition file. The editor expects to read that file in order to provide valuable completion (intellisense) to a developer navigating the API. ts_proto_library is a macro which automatically writes this file to the source tree, which we can observe by deleting it and then running the tests in that package.
There are options to “teach the editor” instead. In Go for example, it’s possible to use the GoPackagesDriver to teach the editor to look in bazel-out for logger.pb.go. But, this is a difficult, brittle configuration to setup on developer machines. And then you’ll just have the next tool or language where the bazel-out location breaks things.
Of course, bazel build itself cannot result in files in the source tree, but we can get a close approximation with a rule called write_source_files. It uses a simple pattern:
  • the build target writes to a file like bazel-out/pkg/foo.pb.go
  • a generated test target asserts that pkg/foo.pb.go in the source folder has the same content
  • a generated executable copies files from bazel-out back to the source tree
  • when the test fails, it prints an instruction how the developer can run the executable
This is the same pattern we use for “golden” or “snapshot” files which live in the source tree.
Read more about this pattern: bazel can write to the source folder