I Went to BazelCon 2025 – Here’s Everything You Need to Know
This year, BazelCon was held at the Omni Atlanta Hotel at Centennial Park for a very special occasion: the tenth anniversary of Bazel 🎉
For me, visiting from Europe, Atlanta made quite the first impression. The city felt bigger than anything I’ve seen back home, and with KubeCon happening right next door, the streets were covered in ads for developer tools. But I wasn’t just there to take in the city. JetBrains was a sponsor of the event, so I joined our booth team at the Solutions Showcase. This was a unique opportunity for me, as I am responsible for the Bazel for CLion plugin within the CLion team. Being there in person allowed me to gather firsthand feedback directly from our users.
Whether you missed the event or just want a recap of the technical highlights, here is my take on the biggest announcements from BazelCon 2025.
Bazel news: The core roadmap
The keynote sessions were packed with updates on the build tool itself. These are my notes about the most important announcements.
Bzlmod is the default, and WORKSPACE is going away
The migration period is nearing its end. The WORKSPACE file has been deprecated since Bazel 7 and is now scheduled for removal in Bazel 9. If you haven’t started migrating your projects, now is the time.
The good news is that many rulesets have already transitioned, and the Bazel team provides migration assistance. You can find the migrate_to_bzlmod.py script in the Bazel Central Registry’s source tree to help translate legacy WORKSPACE files into the new MODULE.bazel format.
Rules moving out of the binary, autoloads off in Bazel 9
The effort to move historically bundled rules into Starlark modules continues. Many rules (such as rules_java) have already been migrated, and rules_cc is one of the last major language rulesets actively being migrated to Starlark.
More crucially for developers, Bazel 9 disables autoloads. This means that even for rules still shipped with Bazel, you must explicitly use load statements in your BUILD files. This is a deliberate step toward hermeticity. However, you can revert to the old behavior using
the --noincompatible_disable_autoloads_in_main_repo flag.
Typed Starlark is coming incrementally
Type annotations are currently an experimental feature enabled by default in Bazel 9. The long-term goal is to introduce a Python-like annotation syntax with actual type checking in Bazel 10. If you want to try type checking in Bazel 9, you can already enable it with --experimental_starlark_type_checking.
This feature is particularly interesting for tools and IDEs because it enables more sophisticated static analysis, providing rich contextual information for features like autocompletion, refactoring, and code navigation.
Note: A new native set type has landed behind --experimental_enable_starlark_set. While this was a long-requested feature, use it with care. The recommendation is still to use depsets for graph aggregation within rules.
Documentation refresh
A new version of Bazel’s docs built with Mintlify was announced. A preview is currently available at preview.bazel.build. The contribution workflow will also be improved. In the future, every PR that makes changes to the docs will automatically generate a new preview build.
Bazel Central Registry updates
Due to some CDN outages this year that affected the availability of the Bazel Central Registry (BCR), resilience is being improved. A new Cloudflare mirror is available and can be enabled with: --module_mirrors=https://bcr.cloudflaremirrors.com.
The BCR website also received usability improvements. You can now view ruleset documentation directly on the site, and new icons indicate quality markers, such as documentation presence or build verification status.
On the horizon
Skycache: Google’s internal Bazel version, Blaze, is already capable of caching analysis results remotely, thereby improving cold build times. Analysis caching (Skycache) is under discussion for open-source Bazel, too. While there is no concrete timeline, this feature would be valuable for tool vendors, as it could enable remote caching of aspect execution and accelerate IDE analysis.
PROJECT.scl (flagsets): Instead of managing flags in growing .bazelrc files, Bazel is exploring a more structured solution: PROJECT.scl, a Starlark dialect for defining canonical build flags in a dedicated .scl file. This more structured and programmable approach to build configurations can be enabled in Bazel 9 with --experimental_enable_scl_dialect.
State of tooling: My top picks
While the core team focused on the platform, the community sessions highlighted a growing ecosystem of developer tools around Bazel. As someone working for a tool vendor, this was my favorite part of the conference – seeing how teams are actually using Bazel beyond just running builds.
Hermetic environments (stop installing tools locally)
Throughout several talks, there was a clear trend toward managing linters, formatters, and CLI tools directly in Bazel. These are the two rulesets being used:
rules_multitool: Provides ergonomic wrappers for downloading and running tools via Bazel, ensuring that CI and every developer’s machine use the same version of every tool.bazel_env.bzl: Creates a Bazel‑managed environment that exposes your tools on a stable path. It works smoothly withdirenv, meaning developers can cd into a directory and automatically get the correct toolchain in their shell.
Note for CLion users: We’re actively exploring how to support this workflow directly in the IDE, so your terminal and IDE always share the same context.
Debugging and forensics
When local builds miss the cache or your rules just don’t behave the way they should, print is no longer the best strategy for debugging (even though it will always be the first tool I reach for 🫠). These tools are more effective:
- Execution Log Parser (execlog): Many sessions recommended running Bazel in CI with the execution log enabled via flags like:
--execution_log_compact_file. The log records precise details of every action Bazel executes during a build and can be parsed with a tool found in the Bazel source tree://src/tools/execlog:parser. Simply diffing parsed logs is the easiest way to compare local and remote builds. - Starlark REPL: If you need to explore Starlark semantics or test syntax without running a full build, there is an REPL available in the Bazel source tree:
//src/main/java/net/starlark/java/cmd:starlark.
Note for CLion users: We plan to add support for these tools directly in our plugin, so you won’t need to clone Bazel and build each tool manually.
Up-and-coming workflows
BCR AI tooling: A new MCP server in the BCR source tree exposes information about your dependencies to AI tools. It allows you to issue prompts like “Update all Bazel modules in my MODULE.bazel file”.
Gazelle for C++: Good news for C++ developers: Gazelle support for C++ is maturing. The gazelle_cc extension developed by EngFlow allows you to generate BUILD files for C++ projects automatically.
Starlark LSPs (starpls): The Rust-based LSP is gaining momentum. We’re also exploring LSP support in the Bazel for CLion plugin to bring you the most up-to-date autocompletion and navigation.
Conclusion
For me, the real highlight wasn’t just the sessions – it was the conversations in the hallway and at the JetBrains booth. Getting face-to-face feedback from our users has given me a backlog full of ideas that will shape our roadmap for the upcoming year. However, if you take only one thing away from this recap, let it be this: Bazel 9 is coming with all its new features, as well as strict migration requirements.
I’m leaving Atlanta excited for what’s next and ready to get back to coding. Do you use the Bazel for CLion plugin? Submit your feature request or drop your thoughts in the comments below. I’ll read all of them, and your feedback genuinely influences our roadmap.
Subscribe to CLion Blog updates
