Bazel projectsAn IntelliJ plugin for
This is an early-access version of our Bazel plugins for IntelliJ, Android Studio, and CLion.
Please see our latest community update for Bazel IntelliJ plugin: Announcing Bazel & JetBrains co-maintenance of IntelliJ IDEA Bazel Plugin.
The Bazel project is hosting a Special Interest Group (SIG) for Bazel IntelliJ IDE plug-in. Details about the SIG and how to join the discussion can be found in the SIG charter.
See the documentation entry on the plugin support across JetBrains products, languages, and operating systems.
You can find our plugin in the JetBrains Marketplace
or directly from the IDE by going to
Settings -> Plugins -> Marketplace, and searching for
Beta versions are usually uploaded to the Beta channel 2 weeks before they become full releases. Ways to install them:
- download and install them manually from the Beta channel page on JetBrains Marketplace
- add the Beta channel to the IDE under
Settings -> Plugins -> Gear Icon -> Manage Plugin repositoriesand add one of the following URLs depending on your product. You can now find the latest Beta under
Settings -> Plugins -> Marketplaceor update the Bazel plugin to Beta if you already installed it.
- IntelliJ IDEA ->
- CLion ->
- Android Studio ->
- IntelliJ IDEA ->
To import an existing Bazel project, choose
Import Bazel Project,
and follow the instructions in the project import wizard.
Detailed docs are available here.
Building the plugin
Install Bazel, then build the target
*:*_bazel_zip for your desired product:
bazel build //ijwb:ijwb_bazel_zip --define=ij_product=intellij-ue-oss-latest-stable
bazel build //clwb:clwb_bazel_zip --define=ij_product=clion-oss-latest-stable
bazel build //aswb:aswb_bazel_zip --define=ij_product=android-studio-oss-latest-stable
from the project root. This will create a plugin zip file at
bazel-bin/<PRODUCT>/<PRODUCT>_bazel.zip, which can be installed directly
from the IDE.
<PRODUCT> can be one of
ijwb, clwb, aswb.
If the IDE refuses to load the plugin because of version issues, specify the
ij_product. These are in the form
<IDE>being one of
intellij-ue, intellij, clion, android-studio,
<VERSION>being one of
oldest-stable, latest-stable, under-dev.
Note that there is a difference between
ue stands for IntelliJ Ultimate Edition and contains additional
<IDE>-oss-latest-stable are aliases for the two IDE versions
that the plugin is officially compatible with at a given time.
maps to the last released IDE version while
<IDE>-oss-oldest-stable maps to the one right before that,
<IDE>-oss-under-dev represents the upcoming version of the IDE that we are working towards
supporting. A complete mapping of all currently defined versions can be found in
You can import the project into IntelliJ (with the Bazel plugin)
via importing the
Compatibility with IDE Versions
You can build the plugin for different IDE versions by adjusting the
option either from command line or by updating the
.bazelproject file to specify
the desired value for
We have three aliases for product versions;
oldest-stableis the oldest IDE version supported by the Bazel plugin released to the JetBrains stable channel.
latest-stableis the latest IDE version supported by the Bazel plugin released to the JetBrains stable channel.
under-devis the IDE version we are currently working towards supporting.
The current corresponding IDE versions of these aliases can be found here.
We welcome contributions to support new IDE versions. However, to make the review process faster and easier, we recommend the following:
We can only accept small pull requests. Smaller pull requests tend to have fewer review comments and hence can get submitted much faster. They also tend to conflict less with our internal code base, simplifying the integration for us. For example, you should have separate pull requests each focusing on a certain incompatible change rather than having a large pull request fixing multiple ones.
Since we continue to support a number of IDE versions while working on a new one, you need to make sure that your proposed changes do not break older versions. Our presubmit pipeline will take care of testing your changes against all the supported versions and lets you know whether it broke anything.
To facilitate merging your changes into upstream, we recommend following our procedure for supporting SDK backward-compatibility.
First consider adjusting the plugin code so that it directly works with different IDE versions. Example strategies for this would be:
For non-trivial incompatible changes, the code for maintaining SDK compatibility lives in sdkcompat and testing/testcompat directories, where
testing/testcompatholds test-only SDK compatibility changes. Each of the two directories contains a sub-folder per supported IDE version with version-specific implementations. The outside API of all classes must be the same across versions, just the implementation may differ. When introducing a new file in this directory, make sure to duplicate it appropriately across all versions.
We follow these three techniques for non-trivial incompatible changes.
Preferred to Adapter and Wrapper when applicable. We add a util-class with only static methods and a private constructor and wrap the changed method by one of the static methods. If the change is small enough, you do not need to create a new util-class and should add the change to BaseSdkCompat class instead. Example: pr/2345
Used when we extend a super class and its constructor is updated. We create a new class extending the changed super class then extend this new class from the plugin code. Example: pr/2352
Created when a new interface is used in a super class constructor. We create a wrapper class that wraps and supplies the old or the new interface based on the SDK version and use this wrapper class in the plugin code. Example: pr/2166
All compat changes must be commented with
#api203. This represents the last API version that requires the code, i.e. the one before the version you aim to support. This is needed to make it easier to find and clean up this functionality when paving old versions.
Compat classes must never import plugin code and we try to keep the logic and code in them as minimal as possible.
We may also be able to accept contributions to fix general issues or adding new features with some caveats:
- Before opening a pull request, first file an issue and discuss potential changes with the devs. This will often save you time you would otherwise have invested in a patch which can't be applied.
- Improvements for old not supported IDE versions will not be accepted. Your changes should target the currently supported IDE versions. You can find a list of these versions here.
- We can't accept stylistic, refactoring, or "cleanup" changes.
- We have very limited bandwidth, and applying patches upstream is a time-consuming process. Large patches generally can't be accepted unless there's clear value for all our users.