This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-02-21
Channels
- # announcements (7)
- # babashka (16)
- # beginners (174)
- # biff (7)
- # calva (20)
- # cider (3)
- # clerk (6)
- # cljsrn (4)
- # clojure (98)
- # clojure-europe (57)
- # clojure-italy (3)
- # clojure-nl (1)
- # clojure-portugal (1)
- # clojure-spec (15)
- # clojure-uk (7)
- # code-reviews (3)
- # cursive (23)
- # data-science (1)
- # datomic (26)
- # dev-tooling (2)
- # emacs (5)
- # figwheel-main (4)
- # fulcro (3)
- # honeysql (20)
- # hyperfiddle (20)
- # malli (8)
- # membrane (31)
- # nextjournal (5)
- # pathom (1)
- # polylith (20)
- # re-frame (14)
- # reitit (8)
- # releases (2)
- # shadow-cljs (50)
- # specter (2)
- # sql (22)
- # xtdb (5)
Hello! I’m experiencing a behavior I don’t understand with Shadow. I have a hierarchy of namespaces:
root.cljs
|
| depends on
ˇ
parent.cljc
|
ˇ
child.cljc
|
ˇ
grandchild.cljc
During a watch, with :cache-level :off
:
• saving the root.cljs
file recompiles the root ns
• saving the parent.cljc
file recompiles parent
and root
• saving the child.cljc
file recompiles child
and parent
, but not root
• saving the grandchild.cljc
file recompiles grandchild
and child
, but not parent
nor root
.
Is it the expected behavior?Full project for reference
yes, this is intended. https://code.thheller.com/blog/shadow-cljs/2019/08/25/hot-reload-in-clojurescript.html#recompile-logic
cache-level only controls what cache is written to disk. watch
also keeps everything in memory while running
if you must have files that are always recompiled use :dev/always
in the ns https://shadow-cljs.github.io/docs/UsersGuide.html#_lifecycle_hooks
> yes, this is intended I must definitely be missing something here because I thought this was a basic shadow-cljs feature. Code changes have always been reflected in the browser right away on my ClojureScript/Shadow-CLJS projects.
I've experienced some very similar problem with a react-native/expo project though https://app.slack.com/client/T03RZGPFR/C6N245JGG/thread/C6N245JGG-1676365851.448239
@U2DART3HA Your shadow-cljs.edn
references an :init-fn root/start!
which doesn't exist in root.cljs
…
>> yes, this is intended > I must definitely be missing something here because I thought this was a basic shadow-cljs feature. Code changes have always been reflected in the browser right away on my ClojureScript/Shadow-CLJS projects. @U05224H0W can you please clarify this ↑ ?
> Your shadow-cljs.edn
references an :init-fn root/start!
You are right this is a mistake. Sorry for the confusion.
No problem. If you have a minimal project you can share on github, I could try to have a look and see if I spot something.
@U5ZHHMZSQ clarify what?
@U05224H0W In a shadow-cljs with :target :browser
code changes anywhere in the sources are rendered right away in the browser (provided you correctly used (defn ^:dev/after-load mount-root …)
read https://code.thheller.com/blog/shadow-cljs/2019/08/25/hot-reload-in-clojurescript.html for more details. as far as shadow-cljs in concerned it is finish when it calls the :dev/after-load
hook. it knows nothing about rendering or even react.
there seems to be an issue in expo/react-native that just stops this rendering process if only something nested changed but not the root
did you set it in the correct place? not uncommon it ends up in the wrong place and do nothing. could also be other things of course. without seeing what you are doing in your code its really hard to give specific advice
I'd still like to know why its necessary because it shouldn't be, but don't have time to look into it currently
I'm just confused and didn't understand the behavior. Thank you for your answer :)
does anyone have a working example of incorporating a shadow-cljs dev build into a webpack dev build such that the final JS has (a) source maps for CLJS and (b) working preloads so the CLJS devtools work?
I'm using deps.edn
for deps management and :npm-module
output, if it matters.
neither are working for me and I wonder if something in the webpack configuration is breaking it.
browser. this is for Metabase, if you want to see the webpack.config.js
https://github.com/metabase/metabase/blob/master/webpack.config.js
yeah, I'm no webpack expert so I'm floundering . the CLJS output has separate source maps for each file. I'm a little suspicious of https://github.com/metabase/metabase/blob/master/webpack.config.js#L311 since it looks like it's expecting inline source maps or per-module ones, and in either case missing the separate per-file maps on the CLJS.
yeah did you try either variant? not all things read input source maps, might require extra config
I didn't know about that BETTER_SOURCE_MAPS
flag until now, I'm trying that.
might need this still https://webpack.js.org/loaders/source-map-loader/
source-map-loader
did the trick for the source maps. if the shadow-cljs :preload
is expected not to work with webpack wrapping it, I'll look into how to get cljs-devtools through webpack. thanks!
npm-module has no clearly defined entries, so somewhere in your JS parts you add if (process.env.NODE_ENV === "development") { require("cljs/shadow.cljs.devtools.client.browser"); require("cljs/shadow.cljs.devtools.client.console"); }
Metabase already had a dev.js
loaded in dev only; it was easy enough to hook in a new namespace that does (devtools.core/install!)
.
thanks for your help!
is there a :dev {:entries [...]}
that merges with the main :entries
? anything else like that? I have some namespaces that are only required in dev mode.
you can do something like this, to overwrite the entries:
:dev {:modules {:module-a {:entries [module-a.core
module-a.dev]}}}
yeah, :preloads
does the right thing except that this output is getting fed to a webpack build. also they don't necessarily agree on dev vs. release builds.
I think the real problem I'm having is that the scripts are doing a release CLJS build, then a dev webpack build. in dev mode the JS includes a dev-only CLJS namespace, which was excluded because it's a release CLJS build, and so it fails at load time. this is a catch-22, and I'll probably have to fix that script so both agree on dev vs. release modes.
yeah, why is the script doing a release CLJS build at dev time? the compile time must be awful :face_with_peeking_eye:
you overestimate how much CLJS is currentl involved 🙂