bazel build at/near head fails in multiple ways.

[bcsgh]

Is bazel an officially supported (and I would hope: tested) usage of google/closure-library? I ask because I'm seeing a lot of low hanging error that suggest some long standing bit-rot issues.

Reproduction:

git clone https://github.com/google/closure-library.git closure-library
cd closure-library
git checkout v20230228 
bazel build ...

The resulting error message is:

ERROR: Error computing the main repository mapping: Every .bzl file must have a corresponding package, but '@io_bazel_rules_closure//closure:defs.bzl' does not have one. Please create a BUILD file in the same or any parent directory. Note that this BUILD file does not need to do anything except exist.

I"m building with 6.1.1:

$ bazel version 
Build label: 6.1.1
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Wed Mar 15 15:44:56 2023 (1678895096)
Build timestamp: 1678895096
Build timestamp as int: 1678895096

That error seems to be a side effect of @io_bazel_rules_closure// being loaded via http_archive without a needed strip_prefix. That can be bypassed via this patch:

--- a/WORKSPACE
+++ b/WORKSPACE
@@ -8,6 +8,7 @@ load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
 http_archive(
     name = "io_bazel_rules_closure",
     sha256 = "9498e57368efb82b985db1ed426a767cbf1ba0398fd7aed632fc3908654e1b1e",
+    strip_prefix = "rules_closure-0.12.0",
     urls = [
         "https://github.com/bazelbuild/rules_closure/archive/refs/tags/0.12.0.tar.gz",  # 2021-06-23
     ],

However, with that I then get the following error:

ERROR: Failed to load Starlark extension '@rules_java//java:defs.bzl'.
Cycle in the workspace file detected. This indicates that a repository is used prior to being defined.
The following chain of repository dependencies lead to the missing definition.
 - @rules_java
This could either mean you have to add the '@rules_java' repository with a statement like `http_archive` in your WORKSPACE file (note that transitive dependencies are not added automatically), or move an existing definition earlier in your WORKSPACE file.
ERROR: Error computing the main repository mapping: cycles detected during computation of main repo mapping

I haven't figured out how to bypass that.

---

NOTE: this seems to mostly be a workspace related issue as things build for the most part from a workspace that loads this repository:

$ bazel build @com_google_javascript_closure_library//... -k
ERROR: $CACHE/external/com_google_javascript_closure_library/closure/goog/editor/plugins/BUILD:63:19: no such package '@com_google_javascript_closure_library//third_party/javascript/safevalues/dom': BUILD file not found in directory 'third_party/javascript/safevalues/dom' of external repository @com_google_javascript_closure_library. Add a BUILD file to a directory to mark it as a package. and referenced by '@com_google_javascript_closure_library//closure/goog/editor/plugins:basictextformatter'
ERROR: $CACHE/external/com_google_javascript_closure_library/closure/goog/soy/BUILD:7:19: no such package '@com_google_javascript_closure_library//third_party/javascript/safevalues': BUILD file not found in directory 'third_party/javascript/safevalues' of external repository @com_google_javascript_closure_library. Add a BUILD file to a directory to mark it as a package. and referenced by '@com_google_javascript_closure_library//closure/goog/soy:data'
ERROR: $CACHE/external/com_google_javascript_closure_library/third_party/closure/goog/mochikit/async/BUILD:7:19: in closure_js_library rule @com_google_javascript_closure_library//third_party/closure/goog/mochikit/async:all_js: 
Traceback (most recent call last):
	File "$CACHE/external/io_bazel_rules_closure/closure/compiler/closure_js_library.bzl", line 374, column 13, in _closure_js_library
		fail("'srcs' must be set when using 'suppress' or 'lenient'")
Error in fail: 'srcs' must be set when using 'suppress' or 'lenient'
ERROR: $CACHE/external/com_google_javascript_closure_library/third_party/closure/goog/mochikit/async/BUILD:7:19: Analysis of target '@com_google_javascript_closure_library//third_party/closure/goog/mochikit/async:all_js' failed
WARNING: errors encountered while analyzing target '@com_google_javascript_closure_library//closure/goog/soy:renderer': it will not be built
WARNING: errors encountered while analyzing target '@com_google_javascript_closure_library//third_party/closure/goog/mochikit/async:all_js': it will not be built
WARNING: errors encountered while analyzing target '@com_google_javascript_closure_library//closure/goog/soy:soy': it will not be built
WARNING: errors encountered while analyzing target '@com_google_javascript_closure_library//closure/goog/soy:soy_testhelper': it will not be built
WARNING: errors encountered while analyzing target '@com_google_javascript_closure_library//closure/goog/soy:data': it will not be built
WARNING: errors encountered while analyzing target '@com_google_javascript_closure_library//closure/goog/editor/plugins:basictextformatter': it will not be built
INFO: Analysis succeeded for only 972 of 978 top-level targets
INFO: Analyzed 978 targets (0 packages loaded, 2 targets configured).
INFO: Found 972 targets...
ERROR: command succeeded, but not all targets were analyzed
INFO: Elapsed time: 0.237s, Critical Path: 0.00s
INFO: 1 process: 1 internal.
FAILED: Build did NOT complete successfully

The remaining issues seem to be a combination of

• lenient closure_js_library rules that have no srcs, only deps.
• closure_js_library rules that should have testonly=True set. (No examples above, but I ran into those while digging on this.)

[shicks]

@gkdn Is this something you're aware of? Can you speak to this at all?

[gkdn]

The problem here is the WORKSPACE definition in this repo is not accurate. However that file is only relevant for testing of the repo (which seems like lacking here). It is not used by the users of repo, they will actually have their own io_bazel_rules_closure definition so I guess that's why this issue wasn't visible outside.

Since there are no local tests, it is possible that some of the targets are miss configured for open-source. If nobody used those libs, they wouldn't be a way to know it other then tests. We only have limited coverage of the libs in rules_closure side.

Anyway, I will test the PR internally but I need a label for that; commented on it.

[bcsgh]

I'll grant that basically all users will have their own WORKSPACE, but at the same time I'd point out that a librarie's own WORKSPACE is de facto documentation of how to use it. I'd say that makes a repo having a fully working build (ideally with passing tests) into a "very nice to have" even if it's not 100% necessary.

Regardless: I'm glad to hear this is getting some attention.