Fork me on GitHub
#shadow-cljs
<
2020-01-13
>
tony.kay00:01:15

Is there a way to reliably detect (in a macro) that shadow is doing a release build?

tony.kay00:01:07

I guess I could just set something in the release config section and check that

tony.kay00:01:48

I figured out what I needed…nvm

cfleming06:01:52

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"))

cfleming06:01:12

When using shadow-cljs watch local I’m not seeing any signs in the log that either main, start or stop are being called.

cfleming06:01:34

Is my expectation that log output would come out on the console with the build output correct?

David Pham07:01:43

You also need to run NodeJS against the output

cfleming08:01:47

Doesn’t watch do that automatically? I would have thought it had to so that code reloading would work.

cfleming09:01:12

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.

thheller10:01:44

watch and hot-reload only work when running locally

thheller10:01:04

in your stop example you are not calling (done) so that would break hot-reload too since it'll wait for stop to complete

thheller10:01:24

but otherwise watch is supported and should be working

thheller10:01:04

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

cfleming10:01:33

I don’t have those in my shadow config, I thought the right versions were built into shadow and supplied?

thheller10:01:40

if you use only shadow-cljs.edn then yes you'll get the right versions

thheller10:01:51

if you offload dependencies to deps.edn or project.clj you might not

thheller10:01:07

you only pasted the build config so I can't tell 😛

cfleming10:01:46

Haha, fair enough. No, I’m not, just plain shadow.

cfleming10:01:59

{: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}}}}

thheller10:01:47

ok that should be working fine

thheller10:01:17

do you run it via node target/local/lambda.js or something aws or whatever cloud you use?

cfleming10:01:22

Assuming that stdout goes to the same place as the compile output, I’m definitely not seeing main, stop or start being called.

thheller10:01:40

it definitely doesn't go to the same place as compile output

thheller10:01:48

shadow-cljs will not run this code for you

thheller10:01:55

if goes whereever you run the code

cfleming10:01:14

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?

thheller10:01:27

no shadow-cljs never runs code for you

cfleming10:01:31

Ok, got it - that’s my problem then 🙂

thheller10:01:36

you have to open the browser or run node 😛

cfleming10:01:53

Thanks, I’ll do that when I’m back coding.

p-himik17:01:53

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?

thheller17:01:25

I guess? how conditional is it? preloads are already dev-only so you can always include it without having it in the release build?

p-himik17:01:19

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.

thheller17:01:25

alter the runtime of the app in what way?

thheller17:01:41

seems like a bad dependency if it does that 😛

p-himik17:01:41

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!

jjttjj19:01:46

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?

darwin19:01:31

have you tried :refer-clojure :exclude [get] instead? you can then refer to it via fully qualified symbol cljs.core/get

jjttjj19:01:44

that works! I noticed exclusion works, didn't think about referring to it fully qualified

darwin19:01:40

my wild guess is that this is a shadow-cljs bug, and that :rename is not properly handled

thheller19:01:50

thats possible. I've never used :rename with :refer-clojure before. didn't even know that was allowed to be honest 😛

kenny23:01:36

How would I tell shadow-cljs about a static edn file that I load in a macro?