Skip to content
Latchkey

Bazel "error loading package" - Fix BUILD/.bzl Eval Errors

Bazel found the package but could not evaluate its BUILD/.bzl Starlark. A bad load() statement, an undefined symbol, or a syntax error stops the package from loading, so its targets never become available.

What this error means

Analysis fails with "error loading package <path>" followed by a Starlark error - an unknown rule, a failed load(), or a syntax problem. Unlike "no such package", the BUILD file exists; it just does not evaluate.

Bazel output
ERROR: error loading package 'services/api': Unable to find package for
@rules_go//go:def.bzl: the repository '@rules_go' could not be resolved.
ERROR: /work/services/api/BUILD.bazel:1:6: name 'go_binary' is not defined

Common causes

Bad or unresolved load() statement

A load() references a .bzl file or repository that does not exist (or is not declared in MODULE.bazel/WORKSPACE), so the symbols it would provide are undefined.

Starlark syntax or symbol error

A typo, a missing argument, or use of an undefined rule name causes Starlark evaluation to fail when Bazel loads the BUILD file.

How to fix it

Fix the load() and declared deps

Point load() at the correct symbol and ensure the providing repo is declared. Load every rule you use.

BUILD.bazel / MODULE.bazel
load("@rules_go//go:def.bzl", "go_binary", "go_library")
# and in MODULE.bazel
bazel_dep(name = "rules_go", version = "0.48.0")

Reproduce the eval error in isolation

Query the single package to surface the exact Starlark error without a full build.

Terminal
bazel query //services/api:all
# or print the evaluated BUILD
bazel query --output=build //services/api:api

How to prevent it

  • Load every rule and macro you use; do not rely on implicit availability.
  • Declare each provider repo in MODULE.bazel (or WORKSPACE).
  • Run bazel query //... in CI to catch load errors before the build.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →