Fork me on GitHub
#shadow-cljs
<
2021-11-22
>
danielcompton17:11:48

I’m trying to suppress a warning in a third-party file:

Resource: node_modules/<file>
 String continuations are not recommended. See 
This SO answer seems to suggest I can disable warnings for this one file with --hide_warnings_for=node_modules/somelibrary, but I’m not quite sure how to provide this argument in my shadow-cljs.edn ? https://stackoverflow.com/questions/47668995/google-closure-suppress-warning-messages-for-a-particular-file

thheller17:11:21

@danielcompton that option doesn't exist in shadow-cljs but I can add it. which npm file causes this?

danielcompton18:11:28

It triggers the warning 25 times when compiling that one file. I looked at the code and using string continuations doesn’t really seem unreasonable given what they’re doing

danielcompton18:11:10

Google Closure does have a @suppress annotation but they don’t seem to allow you to suppress the string continuation warning

thheller18:11:02

yeah I can't find a way to turn it off either. not via the usual mechanism anyways

thheller18:11:31

@danielcompton hmm why are you getting that message in the first place? it is only a debug log? are you running in verbose mode? or :log {:level :debug}?

danielcompton18:11:45

I’m in a brand new codebase so I’m a little unfamiliar, and this is my first time using Shadow CLJS on a major project but I don’t see any debug logs enabled or verbose

thheller18:11:28

@danielcompton in 2.16.6 you can set :js-options {:hide-warnings-for #{"node_modules/ndarray/ndarray.js"}} in your build config to hide those warnings

danielcompton20:11:56

Awesome, thanks!

danielcompton22:11:59

Yep, that worked

dmegas20:11:10

I’m getting a similar error to this older issue https://github.com/thheller/shadow-cljs/issues/427. More specifically

errors in file: .../node_modules/lower-case/dist/index.js
{:js-str-offsets [], :js-esm false, :js-imports [], :js-invalid-requires [], :goog-provides [], :js-language "es3", :goog-module nil, :js-warnings [], :resource-name "node_modules/lower-case/dist/index.js", :js-requires [], :js-errors [{:line 13, :column 13, :message "Character '̇' (U+0307) is not a valid identifier start char"}], :goog-requires [], :tag :shadow.build.npm/errors, :uses-global-buffer false, :uses-global-process false}
ExceptionInfo: errors in file: .../node_modules/lower-case/dist/index.js
for the npm library lower-case. The offending line looks like
İ: "\u0069",
anyone faced anything similar?

dmegas20:11:39

As in the linked issue, I (TokenStream/isJSIdentifier "İ") returns true

dmegas21:11:35

Maybe it could be related to this open issue in google closure https://github.com/google/closure-compiler/pull/3647 :thinking_face:

thheller05:11:52

yeah this isn't something I can control or change from within shadow-cljs

dmegas07:11:03

Is there any workaround, or are such libraries (and those that depend on them) completely unusable with cljs?

thheller07:11:26

that likely won't have that problem

dmegas07:11:56

thank you! I’ll try that

Stephen Wiseman21:11:42

Has anyone experienced any issues with the guava library since upgrading shadow-cljs? It appears that Google moved to using Bazel builds for the closure-compiler. With that, they removed external maven dependencies (in “v20200927” I believe). As a result, lein deps no longer sees guava in the dependency tree as a dependency of shadow -> closure-compiler. On our project, this is causing lein to pick up a lower version (16.0.1) of guava much deeper in the dependency tree as part of an unrelated dependency. This can be confirmed through lein deps :why com.google.guava/guava Then, when doing a shadow build, the build fails as the closure compiler (i think!) tries to use the old version of guava (calling a method that doesn’t exist in guava 16.0.1):

Exception in thread "main" Syntax error macroexpanding at (closure.clj:77:5).
	at clojure.lang.Compiler$StaticMethodExpr.eval(Compiler.java:1742)
	at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3705)
	at clojure.lang.Compiler$DefExpr.eval(Compiler.java:457)
	at clojure.lang.Compiler.eval(Compiler.java:7186)
	at clojure.lang.Compiler.load(Compiler.java:7640)
	at clojure.lang.RT.loadResourceScript(RT.java:381)
	at clojure.lang.RT.loadResourceScript(RT.java:372)
	at clojure.lang.RT.load(RT.java:459)
	at clojure.lang.RT.load(RT.java:424)
	at clojure.core$load$fn__6856.invoke(core.clj:6115)
	at clojure.core$load.invokeStatic(core.clj:6114)
	at clojure.core$load.doInvoke(core.clj:6098)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.core$load_one.invokeStatic(core.clj:5897)
	at clojure.core$load_one.invoke(core.clj:5892)
	at clojure.core$load_lib$fn__6796.invoke(core.clj:5937)
	at clojure.core$load_lib.invokeStatic(core.clj:5936)
	at clojure.core$load_lib.doInvoke(core.clj:5917)
	at clojure.lang.RestFn.applyTo(RestFn.java:142)
	at clojure.core$apply.invokeStatic(core.clj:669)
	at clojure.core$load_libs.invokeStatic(core.clj:5974)
	at clojure.core$load_libs.doInvoke(core.clj:5958)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.core$apply.invokeStatic(core.clj:669)
	at clojure.core$require.invokeStatic(core.clj:5996)
	at clojure.core$require.doInvoke(core.clj:5996)
	at clojure.lang.RestFn.invoke(RestFn.java:551)
	at shadow.build.js_support$eval10779$loading__6737__auto____10780.invoke(js_support.clj:1)
	at shadow.build.js_support$eval10779.invokeStatic(js_support.clj:1)
	at shadow.build.js_support$eval10779.invoke(js_support.clj:1)
...
Caused by: java.lang.NoSuchMethodError: com.google.common.collect.ImmutableSortedSet.toImmutableSortedSet(Ljava/util/Comparator;)Ljava/util/stream/Collector;
	at com.google.javascript.jscomp.deps.ModuleLoader.createRootPaths(ModuleLoader.java:257)
	at com.google.javascript.jscomp.deps.ModuleLoader.<init>(ModuleLoader.java:147)
	at com.google.javascript.jscomp.deps.ModuleLoader.<init>(ModuleLoader.java:48)
	at com.google.javascript.jscomp.deps.ModuleLoader$Builder.build(ModuleLoader.java:139)
	at com.google.javascript.jscomp.deps.ModuleLoader.<clinit>(ModuleLoader.java:408)
	at com.google.javascript.jscomp.DiagnosticGroups.<clinit>(DiagnosticGroups.java:182)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:167)
	at clojure.lang.Compiler$StaticMethodExpr.eval(Compiler.java:1735) 
One confirmed way around this is to set a new version of guava as a top level dependency in our app so it’s picked up in the dependency tree. This works, however, we’d then need to keep manually ensuring that the guava version we specify is compatible with whatever version of the closure-compiler that shadow uses. It’s doable, but it seems like there may be a better solution. Any ideas?