error: no such package '//third_party/protobuf' during Bazel analysis

Answer

Bazel analysis fails with "error: no such package '//third_party/protobuf'" when the analysis phase cannot locate a package at the workspace-relative path third_party/protobuf. For an external dependency like protobuf this almost always means the repository that should materialize that path is not declared, not fetched, or is named differently than the label used in your BUILD files.

Confirmed facts

• Bazel 5.x error output includes the missing package path. Bazel 4.x error output may omit the path unless run with --verbose_fail_output. This change can break automated error-parsing scripts that expect a stable format across versions.
• The experimental flag --experimental_repo_remote changes how repository rules are evaluated and materialized. With remote repository execution the local workspace layout can appear incomplete during analysis, which can mask or delay the "no such package" error until later phases.

Likely explanation, not verified

The question notes the resolver is Package.java scanning the directory structure for BUILD files. In practice the analysis failure for //third_party/protobuf is most commonly an external repository problem, not a missing BUILD file in the source tree. Bazel does not look for a workspace directory named third_party/protobuf unless a repository rule creates it. Manually creating that directory is ignored or overwritten because external repositories live under Bazel's output base.

Steps for this case

1. Check WORKSPACE for a repository rule that provides protobuf. Look for a load statement and a rule naming the repository used by //third_party/protobuf, e.g.:

   load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
   http_archive(
       name = "protobuf",
       ...
   )

   Verify the name matches the label referenced in your BUILD files. If your code references //third_party/protobuf, the repository name and mapping must resolve to that path.
2. Confirm the package is materialized. Run:

   bazel query //third_party/protobuf:all

   If it returns no targets, Bazel does not recognize the package.
3. If the rule exists but the repository is not fetched, force sync and re-analysis:

   bazel sync
   bazel build //...

   Fetch failures usually point to network issues, bad checksums, or an unsupported version.
4. Avoid manually creating third_party/protobuf in the source tree. Bazel manages external repositories and manual files may be ignored.

One diagnostic detail that changes the recommendation: the exact repository rule name and how it is mapped to //third_party/protobuf in your WORKSPACE. If you can share the relevant http_archive or new_git_repository stanza and the label used in the failing target, the fix can be confirmed without guessing the version or mapping.

Note on versions: ensure the protobuf version declared in the repository rule matches what your BUILD files expect. Mismatched versions can allow analysis to succeed but cause compilation errors later.