This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-22
Channels
- # announcements (39)
- # architecture (9)
- # aws (2)
- # babashka (17)
- # beginners (73)
- # calva (6)
- # cider (27)
- # clj-kondo (140)
- # cljdoc (67)
- # cljsrn (1)
- # clojure (99)
- # clojure-dev (4)
- # clojure-europe (35)
- # clojure-nl (7)
- # clojure-spec (19)
- # clojure-uk (2)
- # clojurescript (40)
- # community-development (3)
- # cursive (10)
- # datalevin (2)
- # datavis (2)
- # datomic (27)
- # deps-new (5)
- # events (2)
- # fulcro (38)
- # integrant (6)
- # jobs (3)
- # keyboards (1)
- # leiningen (13)
- # lsp (3)
- # malli (10)
- # meander (5)
- # membrane (1)
- # membrane-term (9)
- # missionary (3)
- # off-topic (29)
- # polylith (3)
- # reagent (3)
- # reitit (5)
- # remote-jobs (2)
- # reveal (7)
- # shadow-cljs (20)
- # tools-build (4)
- # tools-deps (8)
- # vim (10)
- # xtdb (3)
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@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
@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 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?Maybe it could be related to this open issue in google closure https://github.com/google/closure-compiler/pull/3647 :thinking_face:
Is there any workaround, or are such libraries (and those that depend on them) completely unusable with cljs?
you can use webpack as described here https://code.thheller.com/blog/shadow-cljs/2020/05/08/how-about-webpack-now.html#option-2-js-provider-external
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?