3.5.1 IDE Support

A Bazel build is optimized for reproducibility — the same graph, the same flags, the same outputs. An IDE wants the opposite kind of loop: live feedback on every keystroke, even when the code is half-broken, without waiting for Bazel to invalidate and rebuild several layers of dependencies.¹ Bridging those two worlds is what IDE integration for Bazel is about, and community surveys and tooling talks consistently call it out as one of Bazel's top pain points.¹

The boundary is between a hermetic build environment and a responsive editor environment. Keep their inputs aligned where practical: pin the language server, formatter, compiler-facing metadata, and configuration so developers and CI agree on versions and semantics. 3.5.3 Developer Tool Management shows how to put those Bazel-managed tools at stable paths, while 4.6 Toolchains & Platform Resolution explains how a build selects tools for execution and target platforms. But sharing tools does not turn an editor session into a Bazel action. The editor must tolerate unsaved and temporarily invalid code, retain an in-memory snapshot, and often load only part of the repository. Its diagnostics are fast evidence about that partial model. The actual Bazel build or test remains authoritative for its requested configured target graph and execution environment.

There are two established paths, and they diverge by editor ecosystem. JetBrains IDEs run a dedicated Bazel plugin that builds a full project model. VS Code and other LSP-based editors compose a Starlark extension for BUILD files with per-language language servers that talk to Bazel through build adapters or the Build Server Protocol (BSP). Both paths lean on Bazel aspects underneath to extract project metadata. 4.8 Aspects explains that mechanism in depth, while this article stays with the maintainer decision: which integration to pick, what it gives you, and where the sharp edges are.

Bootstrap one supported path

For JetBrains, install the official Bazel plugin, create or check in the project's .bazelproject view, import that view, and run the first sync.² A checked-in project view is the team contract: it records which directories or targets are imported and which Bazel flags sync uses.

For VS Code, install the Bazel Build extension, open the workspace, and configure its language-server command when the executable is not already on PATH (the setting is bazel.lsp.command).³ Then add the language-specific adapter your source language requires. A Starlark extension alone improves BUILD and .bzl editing. It does not manufacture Java, Go, C++, or Swift classpaths.

The JetBrains Plugin Path

For a long time, JetBrains IDEs relied on a plugin maintained by Google under bazelbuild/intellij, covering IntelliJ IDEA, CLion, and Android Studio. That plugin took contributions, but priorities tracked Google's internal needs, so most large customers ended up on private forks — a pattern that neither scaled nor produced a stable shared platform.¹

JetBrains has released its own official Bazel plugin as the successor to the Google-maintained plugin for the main JetBrains IDE path.¹ At the time of the cited tooling discussion, the supported language set centered on JVM (Java, Kotlin, Scala), Go, and Python, while C++/CLion, JS/TS, and Rust support were still separate or less mature paths.¹ Treat that product matrix as ecosystem state, not the core lesson: the stable maintainer choice is whether your team should use the dedicated JetBrains project-model plugin or compose a VS Code/LSP stack. The core of the plugin is open source and mirrored from the IntelliJ monorepo into the public Hirschgarten GitHub repo, which is also where external contributions land.¹

Sync runs aspects over the workspace to collect per-target metadata — source lists, dependencies, classpaths, module info — and uses dynamic rule detection (via bazel query, and bazel mod graph for Bzlmod projects) to generate aspect-loading code only for the rulesets your workspace actually has.⁴ That is what keeps sync from collapsing on an unfamiliar workspace that happens to use, say, rules_kotlin but not rules_scala. The aspect mechanism itself and what providers carry are 4.8 Aspects.

The VS Code and BSP Path

VS Code's story is fragmented by design — each language has its own extension and language server, and Bazel integration means wiring each of them to read the Bazel graph.

For Starlark files themselves (BUILD, .bzl, MODULE.bazel), the Bazel Build VS Code extension pairs with Starpls, a Starlark language server, to give you go-to-definition and completion inside BUILD files.⁵ This is the piece of VS Code integration that is purely about editing Bazel's own configuration — the deeper Starlark dev-tool story is 4.3.4 LSP / IDE Integration.

For code in your project, VS Code uses two broad strategies:

• Build Server Protocol (BSP). BSP originated in the Scala ecosystem as a build-tool-agnostic way for any editor to ask any build tool to run an incremental build and push diagnostics back via LSP.¹ bazel-bsp is one implementation. sourcekit-bazel-bsp is an active effort to wire Swift's SourceKit LSP to Bazel the same way.⁶ The JetBrains Bazel plugin itself started as a BSP prototype, then dropped the abstraction once it became clear that supporting Bazel deeply was more valuable than maintaining a portable layer.¹ BSP is still the natural fit when the editor already expects it — notably Scala via Metals, and increasingly Swift.
• Per-language extensions with a build adapter. The most mature example is Salesforce's Bazel Java SDK, which powers both Bazel Eclipse and a Bazel VS Code Java extension on top of Red Hat's Java language server.⁷ It supports partial project imports — essential in a large monorepo where no developer imports every package — and computes per-package classpaths by combining bazel query with aspects.⁷ On the Go side, gopackagesdriver from rules_go plugs into the standard gopls LSP server as a build adapter, translating gopls's package queries into bazel query + aspect-driven metadata extraction.⁸ Teams sometimes skip BSP entirely and just ship a settings.json that points gopls at a Bazel-aware GOPACKAGESDRIVER binary.⁹

Whichever path the language takes, the shape is the same: a language-aware driver sits between the editor's LSP server and Bazel, and aspects are how that driver reads the graph.

Repository scale makes the project-model boundary operational rather than theoretical. A small workspace may import nearly every target. A large monorepo needs project views, target- or folder-scoped compilation databases, or partial package imports so indexing remains responsive.^5,7 That scope is an editor choice, not a claim that the rest of the graph is irrelevant. CI must still select and validate affected targets. 6.5.1 Affected-Target Service Contract explains how to determine that scope. Likewise, project views decide what a developer loads, while target 0.2.4 Visibility and the later API-boundary policy in H.5.2 Dependency Boundaries decide which dependencies are permitted.

Why the IDE Still Re-Implements So Much

A reasonable question is why an IDE cannot just call bazel build on every save and surface the errors. The answer is latency. One edit can invalidate three levels of dependencies. The incremental rebuild can run for minutes before Bazel comes back with diagnostics.¹ IntelliJ IDEA, which predates LSP by roughly fifteen years, handles this by re-implementing the front half of each language's compiler: it builds its own AST, runs its own type checker, and only asks Bazel for the project model — source roots, classpaths, dependency edges.¹ Rolling out Java 21 or Scala 3 support is therefore a compiler-sized project, not a plugin update, and the same cost reappears for every language the IDE promises to analyze live.

The VS Code side hides some of this work inside the LSP servers (gopls, Red Hat Java LSP, rust-analyzer, etc.), but the core tension is identical: the language server maintains its own in-memory snapshot of the workspace and recomputes diagnostics on each change — the gopls snapshot is explicitly described as an in-memory analogue of Bazel's action cache.⁸ Bazel supplies the project model and the artifacts. The IDE keeps the editing loop responsive.

The friction shows up in concrete places. IntelliJ's Java project model requires sources to be attached to directories, and each directory can belong to exactly one IntelliJ module — but Bazel returns per-target source lists, which may cover only some files in a directory or spread one directory across several targets.¹ The JetBrains plugin solved this only recently. It still recommends directory-level globs in BUILD files for best performance.¹ Project-model mismatches like this one, not the build itself, are the dominant reason IDE syncs are slow on large Bazel repos.

Per-Language Bottlenecks

Current IDE repositories make the generic-versus-language split observable. The official Hirschgarten map routes JetBrains users through its feature matrix and phased sync guide: query builds a quick source model first, then an aspect supplies full dependencies and generated sources. The VS Code Bazel map shows a composition model instead: query-backed target navigation is built in, while bazel-lsp or starpls is configured as an external server. Neither plugin removes the need for a language-specific project model.

Most of the remaining friction is language-specific, and the fix lives in that language's ruleset and driver — not in a generic IDE feature. These are the ones worth knowing about at the maintainer level:

• C++ — compile_commands.json. Clangd and most C++ IDEs want a JSON compilation database: every translation unit with its exact compiler flags.¹⁰ Bazel has no built-in support. The community has converged on a handful of approaches — build interception with bear, bazel aquery, or aspects — each with different trade-offs around tree artifacts and accuracy.¹⁰ The aquery-based hedronvision/bazel-compile-commands-extractor is the de facto standard for projects without tree artifacts.¹⁰ Its public refresh_compile_commands macro exposes target/flag selection and large-workspace exclusions, while the repository map records generated-file and tree-artifact failure routes.¹¹ Upstream uses a custom source-available license rather than an OSI/FSF open-source license, so teams should review redistribution terms before standardizing on it. Depth is in L2.5.1 Compilation Database.
• Go — gopackagesdriver. Ships with rules_go and is the bridge between gopls and Bazel. An aspect reads each target's GoArchive provider and emits per-target JSON metadata that gopls consumes through its standard go/packages loader API.⁸ Depth is in L5.6 IDE Integration (gopackagesdriver).
• Swift / iOS — SourceKit LSP plus rules_xcodeproj. Xcode can be driven by generating a Bazel-backed .xcodeproj via rules_xcodeproj, or replaced altogether with VS Code + the SourceKit LSP server wired to Bazel through BSP (sourcekit-bazel-bsp).⁶ Mobile-specific setup is T2.1 iOS with Bazel.
• Imported Xcode indexes are a separate layer. When compilation runs under Bazel but navigation remains in Xcode, index-import can rewrite checkout, Swift module, and object-file prefixes while copying Clang/Swift index-store data into Xcode. Its README.md example is an illustrative Run Script fragment rather than a complete drop-in integration: derive the actual Bazel index-store inputs and Xcode destination from your build, then use tests/swiftc/ or tests/clang/ to isolate language-specific remapping failures.¹²
• JVM — IDE/Bazel drift on generated sources. Mixed-source and annotation-processor setups can pass IntelliJ's import resolution but fail Bazel, or vice versa. See L1.5 Mixed Java/Kotlin Source Sets for concrete patterns.
• Python — venv-for-IDE. Most Python extensions are still written for a classic virtualenv, and the practical workaround is to have Bazel generate one from the resolved lockfile just for the IDE while keeping builds hermetic. Covered in L3.6 Virtual Environments & Bazel.

An IDE bottleneck in one language often drives team-wide tool choices — which editor you recommend, whether you adopt BSP, whether you fork a plugin — far more than any build performance discussion.