Bazel in the Inner Loop: From Monorepo Graph to Focused Sync
See how Bazel’s dependency graph can separate build scope from IDE scope, helping engineers move through large monorepos without syncing every module.
Loading…
Topic
2 posts about Bazel. Every summary links to the original.
See the idea
See how Bazel’s dependency graph can separate build scope from IDE scope, helping engineers move through large monorepos without syncing every module.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Databricks open-sourced Metals v2, a Scala and Java language server designed to provide low-latency code intelligence for multi-million-line Bazel monorepos, including its 26M-line repository. The project extends Metals v1 by reworking three layers: a build-free, content-addressed mbt repository index; compiler-backed Scala and Java pipelines using a Metals-provided sourcepath; and metadata-first BSP integration that keeps build synchronization off the startup path. Its Java implementation uses javac APIs and a modified Turbine header compiler, which processes close to one million Java lines per second on one thread and supports interactive analysis at nearly 100,000 lines per second in benchmarks. Metals v2 is available in Cursor, VS Code, and Neovim under Apache 2.0, while Databricks reports Cursor’s share of Scala and Java file-open events rising from 40% to 78%.
Grab’s passenger Android monorepo contains roughly 2,000 modules and 11 million lines of code, making Gradle-based Android Studio syncs increasingly slow and memory-intensive even though Bazel handles builds. A cold full sync could exceed 35 minutes, and a survey of 55 developers found that 82% wanted an option to exclude modules from syncing. The team built a custom Focus plugin that uses a dependency graph generated during migrateToBazel, avoids repeating Gradle’s configuration phase, and integrates with Android Studio through a one-click Select → Focus → Sync flow; a Groovy include-shadow technique avoids requiring teams to reorganize settings files. Typical focused syncs fell below two minutes, while reported results show reductions from 35 minutes to under one minute depending on module size, memory usage from 10 GB to 2 GB, and improved Compose preview updates, with broader IDE operations requiring expanded focus or full sync.
The best engineering reads, once a week.