This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-11-22
Channels
- # aleph (5)
- # announcements (9)
- # babashka (9)
- # beginners (127)
- # cherry (1)
- # cider (48)
- # clj-kondo (5)
- # cljdoc (1)
- # clojure (70)
- # clojure-berlin (1)
- # clojure-europe (57)
- # clojure-france (2)
- # clojure-germany (1)
- # clojure-nl (2)
- # clojure-norway (4)
- # clojure-uk (1)
- # clojurescript (2)
- # css (1)
- # cursive (6)
- # emacs (6)
- # gratitude (1)
- # honeysql (5)
- # introduce-yourself (5)
- # jobs-discuss (7)
- # joyride (1)
- # kaocha (3)
- # lsp (1)
- # malli (9)
- # nbb (2)
- # off-topic (91)
- # pathom (7)
- # pedestal (14)
- # re-frame (4)
- # reitit (67)
- # shadow-cljs (46)
- # spacemacs (3)
- # squint (3)
- # tools-build (14)
- # tools-deps (1)
- # vim (3)
Why does shadow-cljs ignore :foreign-libs . See "unsupported" under section https://shadow-cljs.github.io/docs/UsersGuide.html#compiler-options
because its not needed or useful https://shadow-cljs.github.io/docs/UsersGuide.html#cljsjs
Hey 🙂 After bumping shadow-cljs from 2.20.10 to 2.20.11 or 2.20.12, I get an error when building (via lein):
IllegalArgumentException: No matching method legacySetOutputFeatureSet found taking 1 args for class com.google.javascript.jscomp.CompilerOptions
clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:127)
clojure.lang.Reflector.invokeInstanceMethod (Reflector.java:102)
shadow.build.closure/set-options (closure.clj:166)
shadow.build.closure/set-options (closure.clj:122)
shadow.build.closure/convert-goog* (closure.clj:2295)
shadow.build.closure/convert-goog* (closure.clj:2260)
shadow.build.closure/convert-goog (closure.clj:2439)
shadow.build.closure/convert-goog (closure.clj:2389)
shadow.build.compiler/maybe-closure-convert (compiler.clj:1237)
shadow.build.compiler/maybe-closure-convert (compiler.clj:1230)
shadow.build.compiler/compile-all (compiler.clj:1472)
shadow.build.compiler/compile-all (compiler.clj:1349)
shadow.build.api/compile-sources (api.clj:261)
shadow.build.api/compile-sources (api.clj:253)
shadow.build/compile (build.clj:512)
shadow.build/compile (build.clj:493)
shadow.cljs.devtools.api/compile* (api.clj:296)
shadow.cljs.devtools.api/compile* (api.clj:292)
shadow.cljs.devtools.cli-actual/do-build-command (cli_actual.clj:34)
shadow.cljs.devtools.cli-actual/do-build-command (cli_actual.clj:25)
shadow.cljs.devtools.cli-actual/do-build-commands (cli_actual.clj:49)
shadow.cljs.devtools.cli-actual/do-build-commands (cli_actual.clj:38)
shadow.cljs.devtools.cli-actual/main/body-fn--17900--auto----18609 (cli_actual.clj:166)
shadow.cljs.devtools.cli-actual/main (cli_actual.clj:165)
shadow.cljs.devtools.cli-actual/main (cli_actual.clj:132)
clojure.core/apply (core.clj:671)
clojure.core/apply (core.clj:662)
shadow.cljs.devtools.cli-actual/-main (cli_actual.clj:219)
shadow.cljs.devtools.cli-actual/-main (cli_actual.clj:217)
clojure.lang.Var.applyTo (Var.java:705)
clojure.core/apply (core.clj:667)
clojure.core/apply (core.clj:662)
shadow.cljs.devtools.cli/-main (cli.clj:75)
shadow.cljs.devtools.cli/-main (cli.clj:67)
clojure.lang.Var.invoke (Var.java:388)
user/eval140 (form-init17017545089428182543.clj:1)
user/eval140 (form-init17017545089428182543.clj:1)
clojure.lang.Compiler.eval (Compiler.java:7194)
clojure.lang.Compiler.eval (Compiler.java:7184)
clojure.lang.Compiler.load (Compiler.java:7653)
clojure.lang.Compiler.loadFile (Compiler.java:7591)
clojure.main/load-script (main.clj:475)
clojure.main/init-opt (main.clj:477)
clojure.main/init-opt (main.clj:477)
clojure.main/initialize (main.clj:508)
clojure.main/null-opt (main.clj:542)
clojure.main/null-opt (main.clj:539)
clojure.main/main (main.clj:664)
clojure.main/main (main.clj:616)
clojure.lang.Var.applyTo (Var.java:705)
clojure.main.main (main.java:40)
no other changes made, and reverting “fixes” the issue… I tried searching here but didn’t see any mention of this@anders982 you probably have a pinned closure-compiler version. so a dependency conflict. needs the newest version
Hmm, not to my knowledge, but maybe something else is pulling it in. I’ll take a look, thanks!
ah, in clojurescript itself 🙂 thanks again 👍
Can I specify the shadow-cljs build with the command clojure -X shadow-cljs/release
?
Perfect, thank you for the quick answer
How come :release
doesn't support {:optimizations :none}
?
In case of node-script
, I imagine it might make sense to avoid any code size optimization (ie skip the Closure compiler), but still strip out all the development related code.
:compile
still has all the debug loader mechanisms and stuff and just is not a release
build by any means
So there isn't any way to avoid running the closure compiler, but still strip out development related code?
the whole emitted code could be considered development related code unless it runs through the closure compiler
> development related code Yeah, that's a good question. Honestly I just took that phrasing from the docs: https://shadow-cljs.github.io/docs/UsersGuide.html#_release_mode
ok, I define development related code as: code injected by shadow-cljs that is not otherwise specified by your build config. ie. the websocket connection for repl/hot-reload
release
will remove those and also collapse the many input files into the configured output file(s)
watch/compile code is also meant to never run anywhere else than the location output by shadow-cljs
Okay, I think I follow, apart from the last two comments.
Say I want to run a nodejs app in a lambda or similar. If I wanted the "cleanest" code, eg for understanding a stack trace in production, wouldn't it make sense to use the output from compile
?
I don't think understanding a stacktrace of none compiled code is very easy. source maps make that easy
you can also sort of use --pseudo-names
I guess. that gives sort of legible names for :advanced
output, but still source maps are the solution here
Yeah, sounds about right. In the browser I'm used to the browser magically doing all the source mapping for me. In the context of lambdas, I'm usually trying to infer stuff from small snippets of stack traces in cloud watch logs - which is definitely not the way to go.
Do you have any pointers on how a workflow with sourcemaps outside the browser would look?
Alright - I guess minified javascript is not unusual in a Lambda. I'll see what I tooling can dig up. Thanks a lot for the pointers!
yes. you can set :devtools {:ignore-warnings true}
in the build config, but fixing warnings should be the first choice