Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

closure_js_library typecheck fails when depending on j2cl jre #240

Closed
niloc132 opened this issue May 11, 2024 · 2 comments
Closed

closure_js_library typecheck fails when depending on j2cl jre #240

niloc132 opened this issue May 11, 2024 · 2 comments

Comments

@niloc132
Copy link
Contributor

This might be a bug with rules_closure, or with how j2cl's //jre/java:jre uses it, I'm not quite clear.

Describe the bug
Using closure_js_library emits several build rules to facilitate js libraries building and type checking in parallel. One of those rules emits a .i.js file, and another collects the .i.js files produced by dependencies and runs rules_closure's JsCompiler on them with --checks_only.

To Reproduce

  1. Check out latest j2cl, currently 3ecf6f737b6eddab233644072b18025dbcfe8d16
  2. cd samples/helloworld
  3. bazel build 'src/main/java/com/google/j2cl/samples/helloworld:app_typecheck'

Bazel version
Please include version of Bazel that you are running J2CL with:

Bazelisk version: v1.15.0
Build label: 5.4.0
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Thu Dec 15 16:14:25 2022 (1671120865)
Build timestamp: 1671120865
Build timestamp as int: 1671120865

Expected behavior
Type checks for trivial programs pass.

Actual behavior

INFO: Analyzed target //src/main/java/com/google/j2cl/samples/helloworld:app_typecheck (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
ERROR: /home/colin/workspace/j2cl/samples/helloworld/src/main/java/com/google/j2cl/samples/helloworld/BUILD:9:19: Doing library-level typechecking of //src/main/java/com/google/j2cl/samples/helloworld:app failed: (Exit 1): ClosureWorker failed: error executing command bazel-out/k8-opt-exec-2B5CBBC6/bin/external/io_bazel_rules_closure/java/io/bazel/rules/closure/ClosureWorker JsCompiler --checks_only --warning_level VERBOSE --jscomp_off reportUnknownTypes ... (remaining 21 arguments skipped)
bazel-out/k8-fastbuild/bin/external/com_google_j2cl/jre/java/jre.i.js:10776: ERROR - A file cannot be both a goog.module and a script file that contains at least one goog.provide.
goog.provide("jre");
^
  Codes: JSC_MIXED_MODULE_TYPE

bazel-out/k8-fastbuild/bin/external/com_google_j2cl/jre/java/jre.i.js:10781: ERROR - A file cannot be both a goog.module and a script file that contains at least one goog.provide.
goog.provide("jre.checks");
^
  Codes: JSC_MIXED_MODULE_TYPE

bazel-out/k8-fastbuild/bin/external/com_google_j2cl/jre/java/jre.i.js:10794: ERROR - A file cannot be both a goog.module and a script file that contains at least one goog.provide.
goog.provide("jre.logging");
^
  Codes: JSC_MIXED_MODULE_TYPE

3 error(s), 0 warning(s)

Target //src/main/java/com/google/j2cl/samples/helloworld:app_typecheck failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 1.942s, Critical Path: 1.77s
INFO: 2 processes: 2 internal.
FAILED: Build did NOT complete successfully

The issue appears to be that the ijs task emits code that fails checks for j2cl's //jre/java:jre target, as the jre output contains both goog.module and goog.provide declarations. It could be appropriate to split these into separate j2cl_library declarations (that might also make it possible for downstream projects to selectively replace certain java.* packages with their own implementations).

It also might be possible to add js_suppress args, but at first try JSC_MIXED_MODULE_TYPE isnt a valid suppression that can be provided.

Consider adding this task to the samples CI to validate output?

@gkdn
Copy link
Member

gkdn commented May 14, 2024

This is a problem with rules_closure. I actually had a patch to fix it but ended up not sending it. Will resurrect the CL though I'm not sure if it fixes all the problems.

@gkdn
Copy link
Member

gkdn commented May 14, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants