Fork me on GitHub

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 ?


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


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


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


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


@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}?


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


@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


Awesome, thanks!


Yep, that worked


I’m getting a similar error to this older issue 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, :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?


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


Maybe it could be related to this open issue in google closure :thinking_face:


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


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


that likely won't have that problem


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 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(
	at clojure.lang.Compiler$InvokeExpr.eval(
	at clojure.lang.Compiler$DefExpr.eval(
	at clojure.lang.Compiler.eval(
	at clojure.lang.Compiler.load(
	at clojure.lang.RT.loadResourceScript(
	at clojure.lang.RT.loadResourceScript(
	at clojure.lang.RT.load(
	at clojure.lang.RT.load(
	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(
	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(
	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(
	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(
Caused by: java.lang.NoSuchMethodError:;)Ljava/util/stream/Collector;
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.lang.reflect.Method.invoke(
	at clojure.lang.Reflector.invokeMatchingMethod(
	at clojure.lang.Compiler$StaticMethodExpr.eval( 
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?