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.
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 definedCommon 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.
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.
bazel query //services/api:all
# or print the evaluated BUILD
bazel query --output=build //services/api:apiHow 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.