Especially because I see this functioning well day to day: I am in a huge C++ refactoring / cleanup project where I started fixing dependencies (and hidden cycles of them), by adding explicit direct dependencies. As you wrote in the post, the architect who saw my PR spotted that "hmmm, that dependency shouldn't be there; let me fix it."
I find it a good thing that we maintain BUILD files; it detaches the way we reason about dependencies from the actual programming language (is it an "import", or "include"? does it bring transitive/hidden dependencies? etc.) Especially the multi-language huge monorepos I worked with, this helps a lot.
I also try to emphasize to my peers, that Bazel is "not (only) a build command executor", but, besides its many features, it is a "database" you can maintain and query to have a clear view on your dependencies. I'm not sure many devs, for whom Bazel is just a necessary burden, understand this. Those who do, seem to be more productive after all.
I agree!
Especially because I see this functioning well day to day: I am in a huge C++ refactoring / cleanup project where I started fixing dependencies (and hidden cycles of them), by adding explicit direct dependencies. As you wrote in the post, the architect who saw my PR spotted that "hmmm, that dependency shouldn't be there; let me fix it."
I find it a good thing that we maintain BUILD files; it detaches the way we reason about dependencies from the actual programming language (is it an "import", or "include"? does it bring transitive/hidden dependencies? etc.) Especially the multi-language huge monorepos I worked with, this helps a lot.
I also try to emphasize to my peers, that Bazel is "not (only) a build command executor", but, besides its many features, it is a "database" you can maintain and query to have a clear view on your dependencies. I'm not sure many devs, for whom Bazel is just a necessary burden, understand this. Those who do, seem to be more productive after all.