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
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
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.
directories: java/com/google/android/myproject javatests/com/google/android/myproject -javatests/com/google/android/myproject/not_this
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
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.
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
targets: //java/com/google/android/myproject:MyProjectDevTarget -//java/com/google/android/myproject:MyExpensiveTarget //javatests/com/google/android/myproject/...
If set to true, relevant project targets will be automatically derived from the
directories during sync.
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
- very common targets known not to be relevant (e.g. targets with a name
- 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.
If you notice any targets missing or unnecessarily added, or have ideas for
improvements, please let us know (
Help > File a Bug).
Imports another project view.
You may use multiple imports in any project view. Any list type sections
directories) compose. Single-value sections (eg.
override and use the last one encountered, depth-first parse order
(i.e. imports are evaluated as they are encountered).
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.)
- Android Studio: android, 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.
- Android Studio: android, dart, java, kotlin, python, c
additional_languages: dart 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.
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
Usages results, interpreting
@VisibleForTesting annotations, etc.
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.
Sets the maximum number of targets in each bazel build shard.
Only relevant when sharding bazel build invocations.
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.
A set of bazel flags that get passed to all bazel command invocations as arguments (eg. when syncing; to bazel build, test, run, etc).
build_flags: --android_sdk=//third_party/java/android/android_sdk_linux:android_sdk_tools --config=android
A set of bazel flags that get passed to bazel sync actions only. Unlike
build_flags, these are not used for run configurations, so
sync_flags only when absolutely necessary, as it can defeat bazel
A set of bazel flags that get passed to bazel test invocations only. These will not be applied when syncing, so use sparingly, as it can defeat bazel caching.
test_flags: --test_strategy=local --use_sponge=no
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
import_run_configurations: java/com/google/android/myproject/run_project.xml java/com/google/android/myproject/test_project.xml
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.
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.
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.
Points to rules that you want to
bazel run during sync to get typescript
Required if you have requested typescript support in your
ts_config_rules: //com/google/project/typescript:tsconfig //com/google/project/testing/typescript:tsconfig
NOTE: Deprecated. Use
ts_config_rules instead, which allows specifying
Points to a rule that you want to
bazel run during sync
to get typescript support.
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.
NOTE: Deprecated. Prefer the
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.
*.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
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
.bazelproject extension into the same directory. The user can choose
to import any one of these.