Syntactic Sugar & Relative Labels

The fully written form of a label — @repo//package:target — is precise but verbose. In daily use, most of those components can be omitted. Bazel defines a set of shorthand conventions that make BUILD files more readable and CLI invocations faster to type. Understanding which parts can be dropped, and where, prevents a class of common mistakes.

The Eponymous Target Shorthand

When a target has the same name as the last component of its package path, the :target part can be omitted¹. These two labels are equivalent:

//my/app/lib:lib
//my/app/lib

The Bazel style guide recommends this convention explicitly: prefer //x over //x:x when referring to an eponymous target². This is why naming a package's primary target after its directory is a strong convention — it shortens deps lists, CLI commands, and makes the "main thing" in a package discoverable by name alone³. If a package has no natural eponymous target, an alias() can create one³. But don't create an eponymous target just for the shorthand if nothing in the package warrants it².

This shorthand applies everywhere — in BUILD files, in .bzl files, and on the command line. But there's a subtle trap: //my/app always means //my/app:app, even if no such target exists¹. It never means "all targets in the package" or "the package itself." A common mistake in BUILD files is using //my/app to refer to the package — it refers to the target named app¹.

The only context where //my/app means "the package" is inside package_group specifications and in .bzl files that expect a package argument¹.

Relative Labels Inside BUILD Files

Inside a BUILD file, you can reference targets in the same package without the //package prefix¹. The package part and optionally the colon can be dropped:

cc_binary(
    name = "server",
    srcs = ["main.cc", "server.cc"],
    deps = [":utils"],
)

Here :utils refers to a target named utils in the same package — the full form would be //my/app:utils if this BUILD file lives in my/app/.

Convention matters: source files are referenced without a colon prefix ("main.cc"), while rule targets and generated files use the colon (:utils, :gen_header)². The colon is not syntactically required for either — it's a readability convention that distinguishes inputs you wrote from outputs that Bazel produces¹.

cc_library(
    name = "lib",
    srcs = ["x.cc"],
    hdrs = [":gen_header"],
)

Relative labels cannot cross package boundaries¹. If testdata/ is a separate package (it has its own BUILD file), you cannot write testdata/input.txt from the parent package's BUILD file — you must use the full label //my/app/testdata:input.txt¹.

Relative Labels on the Command Line

On the command line, labels without a // prefix are resolved relative to the current working directory⁴. If your working directory is foo/:

This is a convenience for quick iteration — bazel run dev_server from the backend/ directory is equivalent to bazel run //backend/dev_server:dev_server³. But in BUILD files, all cross-package references must use the // form³.

Main-Repository Default

For Level 0, the explicit form for targets in your own repository is simply //pkg:target. That is the normal syntax you will read and write in BUILD files and most command lines.

Official docs also describe a rarer @@//pkg:target form for "refer back to the main repository even from another repository"¹. That detail belongs with Bzlmod and repo mapping later on. At this level, keep the mental model simple: main repo = //..., external repo = @repo//....

Bare Repository Name

When a repository publishes a single rule from a .bzl file with the same name as the repository, a cascading shorthand applies. For example, with @bazel_env providing bazel_env.bzl that exports a bazel_env rule⁵:

load("@bazel_env//:bazel_env.bzl", "bazel_env")

And on the command line:

bazel run @bazel_env

This resolves to @bazel_env//:bazel_env — the eponymous target shorthand applied to the root package of the external repository⁵. This convention keeps load statements short and enables an npx-like bazel run @tool pattern⁵.

Summary of Shorthand Rules