@quest in further investigation is CIDER still a possible culprit? I have more time now to investigate with you if you’re still working on it

Don't think so -- happened upon a threadpool exception on one of those runs, so my current theory is that OSX is sometimes nuking the process due for unknown reasons. Appreciate the follow-up though!

For sure. Good luck to you and feel free to ping if I can help more

thanks. we've chatted a bit more a thread https://clojurians.slack.com/archives/C6N245JGG/p1566280843100200?thread_ts=1566280843.100200&cid=C6N245JGG but nothing is apparent

Yeah I read through it. I’m a bit confused because there’s no lein involved so I expected the jvm settings from the shadow edn file to work

You're not wrong... no idea why it doesn't. For posterity, this is my shadow-cljs.edn file with the jvm-opts set. It's the vanilla re-frame-template https://github.com/Day8/re-frame-template

@quest Thanks for using re-frame-template and investigating the cider issue. Do you think the :jvm-opts is something I should add to the +cider profile ? If it reliably solves the issue then at least cider users won't get any bad surprises when using the template ?

@superstructor I'd recommend it... setting :jvm-opts ["-Xmx1G"] seems to reliably fix the issue 100% of the time. If nothing else, might be worth mentioning on the re-frame template README. This issue could be just on OSX though -- I'm not sure about Windows/*nix. Without the option & with the .shadow-cljs cache already present, it seems to pass/fail every other launch

as soon as you set :lein true the :jvm-opts have no effect since lein will be starting the JVM.

@quest FWIW I can run with -Xmx16G just fine. it should be dying 100% for you with that right?

you could maybe try running clj -J-Xms16G (note -Xms not -Xmx) which sets the min amount of RAM

so it should in theory die instantly if the OS is killing it just because of RAM?

well maybe not. it just reserves the memory but doesn't actually use it

fun little debug utility I just added to master. finds top level forms generating a big chunk of JS.

(in this case forms above 45000 bytes)

not super useful but interesting to see how much code some forms generate

> Form produced 643580 bytes of JavaScript

sounds interesting to me @thheller - output size is a top priority for us atm, and selected info finer-grained than per-namespace sounds useful

I'd stick to build reports for since this number really doesn't mean much.

for example the above generated 643kb is just because it is a macro generating a large (do ...) but all the code is fully removable

but can still be interesting to know. I have done a fair bit of size tuning myself over the years but the build reports have been the only truly useful thing so far

other than digging into the actual sources directly and getting rid of bad concepts that prevented DCE

but for that you kinda need to know how DCE works 😉

ah, yeah, if the reported output is all removable, that makes it a less useful metric

worst offender currently is cljs.spec when only used for fspecs and instrument stuff. meaning not actually at runtime in release builds

it still all ends up in the code if you aren't careful

(and npm deps of course) 😉

hmm - are there any docs around what being careful constitutes - i'm not at all sure we're not missing some tricks

first of all I'd say: don't worry about it

then look at the build reports. eliminate as many JS deps as you can. then start looking at CLJS code and eliminate the obvious offenders (eg. cljs.pprint)

only dig deeper into namespaces using more than like 100kb or so

unfortunately it isn't possible to tell the actual gzip contribution so there may be code that compresses way better than other code

one common offender for me is reagent due the the amount of keywords it might generated

but it doesn't really make sense to optimize the amount of keywords either

ie. not worth worrying about those bytes since there are bigger fish to fry 😉

yeah, we've only got one namespace in the 100kb size range, a couple in the 50kb range, and a lot much smaller - total output size 2.8MB atm. using the build report to figure out how best to modularise seems like the biggest win for us atm

when I run shadow cljs I run this command too sass --watch web/scss/spill/spill.scss web/root/css/app.css to get my sass compiled. Is there any way to run this with shadow?

not currently but maybe soon 😉

cool, btw shadow is great since yesterday I was playing with it. thanks for making this 🙂

I’m trying to set up a project with a pedestal backend and re-frame frontend using clj/deps.edn and shadow-cljs but I can not figure out how to put things together. How to I configure the pedestal backend to be used by shadow-js or am I getting something completely wrong?

shadow-cljs just output files and your pedestal backend should serve them

thats as far as the connection goes. pedestal doesn't need to know anything about shadow-cljs

in your pedestal service conf you can set ::http/file-path "public"

and have shadow-cljs output to public/js (does so by default)

which you then access via (or whatever your module name was)

I stared modifying the re-frame lein template and got confused by the :http-handler option: https://github.com/Day8/re-frame-template/blob/ed85dc98ad383fd03d61acaa8a2092af89bee8c0/src/leiningen/new/re_frame/shadow-cljs.edn#L22

… in the :devtools section of shadow-cljs.edn.

dunno why that is in the that template but it is not used if you use your own pedestal backend

@superstructor the config generated by the template is unnecessarily complex and could be modernized a bit

it generated this

{:lein   true

 :nrepl {:port 8777}

 :builds {:app {:target          :browser
                :output-dir      "resources/public/js/compiled"
                :asset-path      "/js/compiled"
                :dev             {:modules          {:app {:entries [devtools.preload
                                                                     day8.re-frame-10x.preload
                                                                     dummy-10x.core]}}
                                  :compiler-options {:closure-defines {re-frame.trace.trace-enabled?        true
                                                                       day8.re-frame.tracing.trace-enabled? true}}}
                :release         {:modules          {:app {:entries [dummy-10x.core]}}
                                  :compiler-options {:optimizations :advanced
                                                     :pretty-print  false
                                                     :closure-defines {goog.DEBUG                           false
                                                                       re-frame.trace.trace-enabled?        false
                                                                       day8.re-frame.tracing.trace-enabled? false}}}
                :devtools        {:http-root    "resources/public"
                                  :http-port    8280
                                  :preloads     [devtools.preload
                                                 day8.re-frame-10x.preload]
                                  :after-load   dummy-10x.core/mount-root}}}}

and could be this

{:lein true

 :nrepl {:port 8777}

 :dev-http {8280 "resources/public"}

 :builds {:app {:target :browser
                :output-dir "resources/public/js/compiled"
                :asset-path "/js/compiled"
                :modules {:app {:init-fn dummy-10x.core/init
                                :preloads [devtools.preload
                                           day8.re-frame-10x.preload]}}
                :dev {:closure-defines {re-frame.trace.trace-enabled? true
                                        day8.re-frame.tracing.trace-enabled? true}}}}}

I'll see if I can throw together a PR

@thheller thanks! so there are two http-servers running: pedestal and the one that is started by shadow-cljs.

you don't need the one started by shadow-cljs if you have your own backend

Guess I have messed up my project somehow… will start with a clean slate and read the docu again.

there isn't much to it. if you share some config I can probably tell you where you went wrong.

thanks in advance, here is my config: https://pastebin.com/dtSykUxd

:npm-deps   [
                                   {:keycloak-js "^6.0.1"}
                                   ]

your pedestal setup is missing

mainly your service config

service.clj: https://pastebin.com/hMdUt7Gk

ok so the server is configured to run at 8080 and serving the resources/public dir

so everything should be working fine if you open http://localhost:8080

I got it to the point where everything seems to work but the automatic reload. I get the HUD showing up and telling me view.cljs has been reloaded but the page does not update.

right you removed the hook config

open the telifit-web/core.cljs

and change (defn mount-root [] to (defn ^:dev/after-load mount-root []

this will well shadow-cljs to call that function after it has reloaded code

and that fn will re-render your ui

Thanks a lot 🙂 … it is working now. Will also have a look at your response to @superstructor regarding the unnecessarily complex shadow-cljs.edn…

{:deps {:aliases [:cljs]}
 :source-paths ["src/cljs"]
 :builds {:app {:target :browser
                :output-dir "resources/public/js/compiled"
                :asset-path "/js/compiled"
                :modules {:app {:entries [telifit-web.core]
                                :preloads [devtools.preload
                                           day8.re-frame-10x.preload
                                           re-frisk.preload]}}
                :dev {:compiler-options {:closure-defines {re-frame.trace.trace-enabled? true
                                                           day8.re-frame.tracing.trace-enabled? true}}}
                }}}

I had a look at you pull request for the template and applied the changes to my code.

Thank you very much for your support. Not only shadow-cljs is impressive but also your support to the community in general!

*Edit: found the known issue affecting CIDER pprinting https://github.com/thheller/shadow-cljs/issues/510

From thheller's response it sounds like something is stripping newlines between the browser -> Emacs REPL output. I get a single line of EDN output on my setup

Thanks for the review and PR @thheller Much appreciated! I have merged and will release shortly.

hi! what can I use so a namespace gets reloaded but def with atoms aren't redefined? defonce doesn't seem to work for me

Hi! I am injecting on any live site (with a chrome extension) my app js (js/main.js) produced by shadow-cljs

I am getting 404 errors when page tries to load “https://www.a-live-site.com/js/cljs-runtime/…”

I would want the page to look for “http://localhost:3000/js/cljs-runtime/…”

Is there a way to do that?

I suppose this is obvious, but can’t find out

thanks!

I was able to serve a release build, but not ideal when I want a reload workflow for development

Done and released. Thanks 🙂

Released 🙂

Released @thheller's improvements to the template. Thanks 🙂

hey all, have a kind of funky situation where I’m targeting an electron browser window with node integration enabled but loading my js via a script tag. I’d like to load it via the script tag as opposed to bundling the file with my electron distribution so code updates are automatic and don’t require an app update. setting my target to :browser w/ the associated config options leads to my getting weird errors like The required JS dependency "path" is not available... despite path being installed and available in the correct dir. setting the target to :node-script appends an #!/usr/bin/env node to the output file, which doesn’t actually work in a browser context when loaded via a script tag. anyone have an idea for either 1) how to specify that node requires are kosher in a :browser target or 2) strip the #!/usr/bin/env node heading from the output file in a :node-script target?

@superstructor cool. can you tell me how to test that template locally? I always forget 😛

if you want REPL pprint you can set :devtools {:repl-pprint true}

but cider seems to expect some of its own stuff to do the pprint and I have no clue how that side works

I don't blame you, went digging through the code this morning and had a rough time of it. I added what little I could figure out at https://github.com/thheller/shadow-cljs/issues/510#issuecomment-523633532

@leontalbot there is support for building chrome extensions directly. did you use that or did you use :browser? https://github.com/thheller/shadow-cljs/issues/279

@mss :node-script is for node scripts. it is not intended to run in the browser. you can use the regular :target :browser and set :js-options {:js-provider :require}

defonce is exactly for that case. dunno why it wouldn't work though? what is your build setup?

I used Tampermonkey + :browser

interesting, so that could fix the wrong cljs-runtime urls app needs to get?

you can control which URL it is trying to connect to via :devtools-url https://shadow-cljs.github.io/docs/UsersGuide.html#proxy-support

or just :asset-path "..."

but the whole things isn't really designed to be injected into arbitrary pages

and can very easily break

:asset-path works, then getting CORS error

you might get a bit further by setting :devtools {:loader-mode :eval}

but yeah injecting a dev build is gonna break in various ways

this is my shadow-cljs.edn

{:source-paths ["src/cljs"]
 :dependencies [[day8.re-frame/http-fx "0.1.6"]
                [dorothy "0.0.7"]
                [reagent "0.8.1"]
                [re-frame "0.10.8"]
                [datascript "0.17.1"]
                [re-com "2.5.0"]]
 :dev-http {9500 "resources/public/"}
 :builds {:app {:output-dir "resources/public/js/"
                :asset-path "/js"
                :target :browser
                :compiler-options {:output-feature-set :es6}
                :modules {:main {:init-fn clograms.core/init}}
                :devtools {:after-load clograms.core/mount-root}}}}

if I add ^:dev/once to the ns that has the atom then everything is fine (but I can't reload code there)

uhm defonce is an actual (defonce the-atom (atom {})?

it is exactly that

(defonce storm (atom {}))

ok that shouldn't be reassigned then? unless you are manually calling (reset! storm {}) or something?

you can verify that it is only set once by doing (defonce storm (do (prn :init-the-atom) (atom {}))

yeah I'm seeing the :init-the-atom again when reloading

thats odd. is the name maybe conflicting with something?

wow you are right, I have an alias with the same name

ns alias? that doesn't matter

yeah ns alias

well, that did the trick

I renamed the atom to storm-atom and now I only see the :init-the-atom once

and what was the ns alias?

(:require ["@projectstorm/react-diagrams" :as storm])

ah ok its a JS alias. I guess that might confuse things

now it works, thanks again!

Yeah its a bit magic. Anytime you run the lein new re-frame... command within the re-frame-template project dir lein will use that copy and not look for the jar.

well, :loader-mode :eval works! thanks! only thing is I see “connection fail” bottom left warning on ui

that is controlled by :devtools {:devtools-url ""} since that by default will try to use the current document.location