This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-13
Channels
- # aleph (1)
- # announcements (14)
- # aws (8)
- # babashka (3)
- # beginners (49)
- # cider (6)
- # clara (7)
- # clj-kondo (58)
- # cljs-dev (17)
- # clojure (65)
- # clojure-dev (45)
- # clojure-europe (5)
- # clojure-italy (4)
- # clojure-nl (25)
- # clojure-norway (3)
- # clojure-uk (68)
- # clojurescript (10)
- # cursive (5)
- # datomic (12)
- # emacs (24)
- # fulcro (149)
- # hoplon (56)
- # kaocha (2)
- # luminus (18)
- # malli (7)
- # off-topic (12)
- # other-languages (82)
- # reagent (16)
- # reitit (7)
- # shadow-cljs (44)
- # spacemacs (4)
- # tools-deps (48)
- # xtdb (17)
Is there a way to reliably detect (in a macro) that shadow is doing a release build?
Is it expected that watch
would work with a :node-script
target? I have the following config:
{:target :node-script
:main lambda.serve/main
:output-to "target/local/lambda.js"
:devtools {:before-load-async lambda.serve/stop
:after-load lambda.serve/start}}}}
and in my lambda.serve
ns I have:
(defn main [& args]
(println "Hello")
(js/console.log "Hello")
...etc etc...)
(defn start
"Hook to start. Also used as a hook for hot code reload."
[]
(js/console.warn "start called")
(main))
(defn stop
"Hot code reload hook to shut down resources so hot code reload can work"
[done]
(js/console.warn "stop called"))
When using shadow-cljs watch local
I’m not seeing any signs in the log that either main
, start
or stop
are being called.
Is my expectation that log output would come out on the console with the build output correct?
You also need to run NodeJS against the output
Doesn’t watch do that automatically? I would have thought it had to so that code reloading would work.
Thinking about it, I assume the code generated by watch contains code to connect back to the server. I’ll try when I’m back at my computer.
in your stop example you are not calling (done)
so that would break hot-reload too since it'll wait for stop to complete
check your dependencies though. shadow-cljs only works with the newer closure-compiler and closure-library versions. if you have the old one things break in weird ways
I don’t have those in my shadow config, I thought the right versions were built into shadow and supplied?
{:source-paths ["src/shared" "src/deploy" "test" "src/local"]
:dependencies [[com.andrewmcveigh/cljs-time "0.4.0"]
[funcool/promesa "4.0.2"]
[appliedscience/js-interop "0.1.21"]
[cljs-bean "1.5.0"]]
:builds {:production
{:target :node-library
:compiler-options {:optimizations :simple}
:output-to "target/production/lambda.js"
:exports {:webhook lambda.webhook/webhook
:buy lambda.buy/pre-auth
:renew lambda.renew/pre-auth
:quote lambda.quote/quote}}
:test
{:target :node-test
:output-to "target/test/node-tests.js"
:autorun true
:ns-regexp "-test$"}
:local
{:target :node-script
:main lambda.serve/main
:output-to "target/local/lambda.js"
:devtools {:before-load-async lambda.serve/stop
:after-load lambda.serve/start}}}}
do you run it via node target/local/lambda.js
or something aws or whatever cloud you use?
Assuming that stdout goes to the same place as the compile output, I’m definitely not seeing main, stop or start being called.
So maybe that’s my misunderstanding, I thought that when using watch
it would run the output automatically, so that shadow could reload - is that not the case? Do I have to run it locally using node?
I want to make a conditional preload coming from a conditional dependency (same condition), and I already use deps.edn
.
The best way to do this would be via --config-merge
, right?
I guess? how conditional is it? preloads are already dev-only so you can always include it without having it in the release build?
Right now it's basically for experimenting, because sometimes dev dependencies seem to alter the runtime of the app. The condition is needed just to be able to run the server with different preloads an dev dependencies when needed.
Yeah, probably. TBH don't remember the details and have probably removed the dependency by now - I just have it on my backlog to check how to do it. Anyway, thanks!
I have
(:refer-clojure :rename {get core-get})
In a cljc file and a function named get
. The initial compilation is fine but then whenever I reload I get the warning:
get already refers to: cljs.core/get being replaced by: mylib.core/get
Is there something else I have to do to prevent this? Is this just a cljs thing unrelated to shadow?have you tried :refer-clojure :exclude [get]
instead? you can then refer to it via fully qualified symbol cljs.core/get
that works! I noticed exclusion works, didn't think about referring to it fully qualified
my wild guess is that this is a shadow-cljs bug, and that :rename is not properly handled