Why Bazel?

A build system which you wouldn't ever had heard of, is actually very good. This is not a new tool but this is an old tool which is currently in usage by many big repositories.

This is bazel. The actual bazel which according to wikipedia ↗

"Bazel is a village in Belgium, in the municipality of Kruibeke in the province of East Flanders. The village is home to the Wissekerke Castle. The municipality of Bazel merged into Kruibeke in 1977.".

But why are we talking about this? NO WE ARE NOT TALKING ABOUT THIS. By bazel i mean bazel build ↗ . It is a build system which is fast, correct, and extensible build tool with integrated testing that supports multiple languages, repositories, and platforms in an industry-leading ecosystem. and yes it is also for intense scalability.

I got to know about bazel build system through a random google search about centeral repositories, yes i know this sounds wierd but yeah it is what it is. I've been using this since then, my majority work makes use of bazel(7), where i use both WORKSPACE.bazel and MODULE.bazel. But I have high hopes with version 9.

The build system uses the 3 golden files to initiate the declarative BUILD system,

| BUILD.bazel | MODULE.bazel | WORKSPACE.bazel |

In versions of after bazel(7). They started to maintain Bzlmod replacing the legacy WORKSPACE system, which i will talk about later in this blog.

whisphers: it also maintains the .lock file, for Module.bazel.

The reproducibility of bazel is hermetic yes you heard me right, where make sucks in reproducibility bazel provides you hermicity.

The Learning Curve.

I agree that declaring bazel build system can be complex for some people but once you know how things work you'd be glazed by this design philosophy, much like the other tech it also has the learning curve, just like other good software.

In recent versions of Bazel they started to maintain Bazel Central Registry ↗ just like maven repository, As of March 2025 Bazel Central Registry hosts more than 650 modules. This actually improved the complexity issue this makes it even more easier to introduce external dependencies.

With Bazel 9, They will completely remove WORKSPACE, functionality, and Bzlmod will be the only way to introduce external dependencies in Bazel. read more about this ↗ .

How it works?

just go to the Bazel Central Registry ↗ , select the dependency put it into MODULE.bazel and create BUILD.bazel, and boom you're good to go.

here is a small reporoducive example of how you can initiate the BUILD.bazel file

rust_binary(
    name = "axolotl",
    srcs = glob(["src/**/*.rs"]),
    data = ["tests/html/test.html"],
    edition = "2024",
)

and add the dependency to MODULE.bazel.

bazel_dep(name = "rules_rust", version = "0.61.0")

also use bazel query //... to check all targets in the bazel build system. To identify all Bazel build targets with public visibility (either explicitly declared or inherited via package defaults), use a combination of bazel query commands and visibility analysis:

For contributors:

If you want to identify all Bazel build targets with public visibility (either explicitly declared or inherited via package defaults), you can try to query because some targets are directly marked as public with visibility = ["//visibility:public"] in their BUILD file. for example:

bazel query 'attr(visibility, "//visibility:public", //...)'

from what i know there’s no direct way to query default_visibility, so you’ll have to rely on manual checks or scripting to handle packages with public defaults. It’s a bit of a pain, but that’s how Bazel works right now. Also, for a project setting default_visibility = public in a package can expose more than you intend, especially in big projects. It’s a good idea to avoid this unless it’s absolutely necessary.

I'd love if you give it a try the Bazel Central Registry ↗ needs to grow more users mean more contributors more contributors mean better support. Making the blog short for now, this is it.