I’ve heard it from people new to Bazel but also from people very familiar with the Bazel ecosystem: BUILD files must go away. And they must go away because they are redundant: they just repeat the dependency information that’s already encoded in the in-code import/use statements.
Hearing this from newcomers to Bazel isn’t surprising: after all, most newcomers are used to build tools that provide zero facilities to express dependencies across the sources of your own project. Hearing it from old-timers, however, is disappointing because it misses the point of what BUILD files can truly offer.
In my opinion: if that’s how you are writing BUILD files, you are holding them wrong. There is much more to BUILD files than mindlessly repeating import statement dependencies. Let’s see why.
The problem
Suppose you are given the following change to review:
--- a/src/main/com/example/compiler/parser/Parser.java +++ b/src/main/com/example/compiler/parser/Parser.java @@ -1,8 +1,10 @@ package com.example.compiler.parser; import com.example.compiler.ast.Ast; +import com.example.compiler.ast.Statement; import com.example.compiler.lexer.Lexer; import com.example.compiler.lexer.Token; +import com.example.compiler.utils.FileReader; // Parser for a simple language. class Parser {
By looking at this diff, possibly from a Pull Request (PR) review, you can guess the following:
The com.example.compiler.parser Java package already depends on the com.example.compiler.ast package.
The com.example.compiler.parser Java package already depends on the com.example.compiler.lexer package.
The addition of the import com.example.compiler.ast.Statement line does not modify the dependency graph: the edge from the parser package to the ast package existed beforehand, and this new import statement is just leveraging it.
... continue reading