Project Views
IntelliJ with Bazel

Project Views (.bazelproject files)

Overview

The project view file (*.bazelproject) is used to import a subset of Bazel packages into the IDE. The project view determines which rules are imported and how.

The project view file uses a python-like format with 2 spaces indentation and # comments. You can share the .bazelproject file between projects, use your own copy, or both.

In general, you can start with just directories and targets and add more sections as you want to further tweak your IDE workspace.

Creating the Project View

The easiest way is to import an existing .bazelproject file. If you already have a different project open in the IDE, this action is available from File > Import Bazel Project.

To modify an existing project, use Bazel > Project > Open Local Project View File. Note, you can still use an import of a shared .bazelproject, and then include additional directories and targets below.

After editing the project view file, run Bazel > Sync > Sync Project with BUILD files to pick up the changes.

directories

Required

Directs the IDE to index (but not resolve) all the files within the given directories, which will also make them accessible in the project directory list. Each directory entry must point to a workspace directory. All files under directories are included in the import. Directories are always recursive.

If you want to exclude directories, prefix the entry with a minus ("-") sign.

Note: Including a directory only imports the files. If you want to resolve your source, it must be reachable via a target (see below).

Example:

directories:
  java/com/google/android/myproject
  javatests/com/google/android/myproject
  -javatests/com/google/android/myproject/not_this

targets

Required

A list of bazel target expressions. To resolve source files under an imported directory, the source must be reachable from one of your targets. Because these are full bazel target expressions, they support /... notation.

The more targets you have, the slower your Bazel sync will be. You can use negative targets to have bazel ignore certain targets (eg. -//java/com/google/foo:MyExpensiveTarget). See also the no-ide tag.

Example:

targets:
  //java/com/google/android/myproject:MyProjectDevTarget
  -//java/com/google/android/myproject:MyExpensiveTarget
  //javatests/com/google/android/myproject/...

Note: Many IDE features may not function fully without the semantic information pulled from these targets. Each file necessary for one of the listed targets will be resolved in order to build a semantic model about names, signatures, annotations, methods, fields, imports, files matched by a BUILD glob, other external references, etc.

Some IDE features that use information resolved from these targets:

  • Understanding type hierarchies for error reporting and code completion
  • Reporting errors when a reference can't be resolved (e.g. due to a missing import or typo)
  • Supporting navigation to referenced code (Ctrl+Click, Navigate → Declaration, Navigate → Implementation) or referencing code (Find Usages, Show Usages, Call Hierarchy)
  • Updating existing references when performing cross-file refactors (e.g. renaming public methods, moving a class to another package...)

import

Imports another project view.

You may use multiple imports in any project view. Any list type sections (eg. directories) compose. Single-value sections (eg. workspace_type) override and use the last one encountered, depth-first parse order (i.e. imports are evaluated as they are encountered).

Example:

import java/com/google/android/myproject/.bazelproject

workspace_type

Use this to specify the kind of languages you want to support in the project. This setting controls certain global project structure settings like the kind of SDK we configure (eg. "java" gets a normal Java SDK, but "android" will get an Android SDK).

If omitted, we use the default workspace type for your IDE.

This setting is usually only necessary if you want to use Android Studio for a Java-only project (eg.)

Possible values

  • IntelliJ: java, javascript, python, go
  • Android Studio: android, java

Example:

workspace_type: java

additional_languages

By default, we import the language classes implied by your workspace type. If you want additional languages in your workspace, you can use this attribute.

Possible values

  • IntelliJ: android, dart, java, javascript, kotlin, python, typescript
  • Android Studio: android, dart, java, kotlin, python, c
  • CLion: dart

Example:

additional_languages:
  dart
  typescript

java_language_level

IntelliJ/Android Studio only

Use this to override the language level used by the IDE. Normally this is inferred from the corresponding java_toolchain rule reachable from your targets.

Example:

java_language_level: 8

test_sources

A list of workspace-relative glob patterns, matching directories. Determines which sources IntelliJ treats as test sources. This should only be applied to actual tests, not test utility classes.

IntelliJ uses this information in a variety of ways, e.g. filtering Find Usages results, interpreting @VisibleForTesting annotations, etc.

Example:

test_sources:
  javatests/*

shard_sync

Allows sharding bazel build invocations when syncing and compiling your project.

This is useful for large projects for which bazel cannot build the entire project with the default memory allocation.

If you get an out of memory error running bazel sync, consider adding this flag and retrying.

Example:

shard_sync: true

target_shard_size

Sets the maximum number of targets in each bazel build shard.

Only relevant when sharding bazel build invocations.

Example:

target_shard_size: 500

exclude_library

IntelliJ only

A set of workspace-relative glob patterns that match jars. Can be used to resolve classpath conflicts where the one version policy is violated. You should normally not have to use this.

NOTE: You can exclude a library by right-clicking on it in the project tree and choosing "Exclude Library".

NOTE: This attribute matches jars in the output tree, not rules.

Example:

exclude_library:
  third_party/maven/libraries/guava*.jar

build_flags

A set of bazel flags that get passed to all bazel command invocations as arguments (eg. when syncing; to bazel build, test, run, etc).

Example:

build_flags:
  --android_sdk=//third_party/java/android/android_sdk_linux:android_sdk_tools
  --config=android

sync_flags

A set of bazel flags that get passed to bazel sync actions only. Unlike build_flags, these are not used for run configurations, so use sync_flags only when absolutely necessary, as it can defeat bazel caching.

Example:

sync_flags:
  config=gmscore_arm7

import_run_configurations

A list of XML files which will be imported as run configurations during bazel sync. By default these run configurations will be updated during sync to match any changes to the XML.

Bazel run configurations can be exported to XML using the Bazel > Export Run Configurations action. See the full workflow for more details.

Example:

import_run_configurations:
  java/com/google/android/myproject/run_project.xml
  java/com/google/android/myproject/test_project.xml

android_sdk_platform

Android Studio only

Selects which android platform from your SDK directory to use. Corresponds to a subdirectory in ~/<sdk>/platforms.

Required if your workspace_type is "android". Note that this is implicit if you're using ASwB.

Example:

android_sdk_platform: "android-experimental"

android_min_sdk

Android Studio only

Sets the global minimum SDK level to use for lint warnings in Android Studio.

We can't use the <uses-sdk android:minSdkVersion=... /> values from the manifests because there could be multiple values, and we can only have one, due to the way the Bazel plugin handles sources.

Example:

android_min_sdk: 19

generated_android_resource_directories

Android Studio only

A list of paths into the genfiles tree containing generated resources you'd like to whitelist for inclusion.

By default generated resources are dropped for performance reasons. If you have a rule that generates resource xmls from scratch, you can use this rule to have them added to the project view.

During sync, the IDE will warn you about any dropped generated android resource directories. You can double-click on the warning to automatically add the correct entry to your project view.

Please don't use this to add resources that have been filtered from checked-in resources. The IDE will not work well with this -- it will be slower, and you will not be able to edit your resources anyway in the IDE since it won't understand that your read-only genfiles resources actually correspond to some other checked-in sources.

Example:

generated_android_resource_directories:
  java/com/google/android/apps/myapp/genresources/res

ts_config_rules

IntelliJ only

Points to rules that you want to bazel run during sync to get typescript support.

Required if you have requested typescript support in your additional_languages.

Example:

ts_config_rules:
  //com/google/project/typescript:tsconfig
  //com/google/project/testing/typescript:tsconfig

ts_config_rule

NOTE: Deprecated. Use ts_config_rules instead, which allows specifying multiple ts_config targets.

IntelliJ only

Points to a rule that you want to bazel run during sync to get typescript support.

Example:

ts_config_rule: //com/google/project/typescript:tsconfig

import_target_output

NOTE: Deprecated. You should never need to use this project view directive.

Forces a import of a particular rule's outputs. This is useful if you have rule under your source directories that you want to import as jars instead of sources.

See also intellij_import_target_output.

Example:

import_target_output:
  //java/com/google/android/apps/config:MyConfigSettings

exclude_target

NOTE: Deprecated. Prefer the no-ide tag.

Drops a target completely, ignoring its sources and outputs. The target will still be built and the IDE is still aware that a rule of this name exists.

See also intellij_exclude_target.

Example:

exclude_target:
  //java/com/google/android/apps/myapp:MyExpensiveJar

Source control

.bazelproject files can be checked into source control. By convention, they live next to the BUILD file people import.

If your project has multiple different views, you may check in multiple files with the .bazelproject extension into the same directory. The user can choose to import any one of these.