Project Views
IntelliJ with Bazel

Project Views (*.bazelproject files)


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 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.



A list of directories to include in your project. All files in the given directories will be indexed (allowing you to search for them) and listed in the Project tool window. If a file is not included in your project, it will have a yellow tab, and you will see a warning when attempting to edit it.

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

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.





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.

Note: Many IDE features rely on the information resolved from these targets. Without them, dependencies and generated files will not be known, appearing red and failing to auto-complete. To make the most of your IDE, you should ensure at least the files you actively work on are reachable from your targets, and sync to keep them resolved.

Targets are built during Bazel Sync, so 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.

If derive_targets_from_directories is set, there’s generally no need to include targets underneath your project here, though you may want use this section to manually exclude some automatically added targets.




If set to true, relevant project targets will be automatically derived from the directories during sync. Note that directories from all transitive imports are included.

We try to limit this to only syncing relevant targets, and do this by filtering on rule type, along with a set of heuristics. Specifically, we look at the set of targets under your directories, recursively (accounting for excluded directories). Out of those, we remove:

  • rule types we don’t recognize as being relevant to resolving code, from a list we maintain, similar to this one
  • targets with the manual tag
  • very common targets known not to be relevant (e.g. targets with a name matching .*@pytype@.*, or .*_java_static_analysis)
  • rule types for languages not enabled/supported (e.g. C++ targets in IntelliJ, Java targets in CLion, TypeScript targets if you haven’t enabled TS support)

Any targets included/excluded explicitly in the ‘targets’ section take priority. After targets from all directories sections are derived, target inclusions/exclusions from all targets sections are applied.

If you notice any targets missing or unnecessarily added, or have ideas for improvements, please let us know (Bazel > File a Bug).


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).


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


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, dart
  • Android Studio: android, java, dart


workspace_type: java


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, go
  • Android Studio: android, dart, java, kotlin, python, c
  • CLion: dart, javascript, python, typescript




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.


java_language_level: 8

Only for IntelliJ, you can also set the java language level to enable preview features.


java_language_level: jdk_17_preview


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.




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.


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


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.




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.



Source control

*.bazelproject files can be checked into source control. By convention, they live next to the BUILD file people import. While many teams name the file simply .bazelproject, we recommend adding a prefix like myteam.bazelproject since Piper treats dotfiles differently (most importantly, it won’t automatically add them to your CLs).

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.