Fork me on GitHub

Hi, small question about lifecycle hooks, I have a re-frame app that defines this hook in it's core namespace:

(defn ^:dev/after-load mount-root []
        (reagent/render [views/main-panel]
                        (.getElementById js/document "app")))


I've added a :workspaces build in shadow-cljs.edn to support Now, whenever I update the code, the workspaces app goes blank because of this hook. Is there a way to disable it for that build, but keep it for the regular build?


@ozfraier I would recommend splitting the namespaces so this can't happen. there is currently no way to disable hooks per build. you can move the hook config to the build though. so no meta but :devtools {:after-load } in the build config


@royalaid shadow-cljs never even opens the package.json in your project. I assume you want to configure where it looks for actual npm packages and that you can configure per build via :js-options {:js-package-dirs ["addBankAccount/node_modules" ...]}


and structure wise I would probably keep all sources in <project>/src/main and then just have it output separate files to <project>/lambdas/foo/... so each lambda can have its own config and stuff in its own folder


enforcing that structure for everything seems rather cumbersome to me πŸ˜›


Yeah, it's because the cli tools zip the dir and just upload it after running your build step so it has to be a specific shape πŸ˜•


I am sure I could make some magic happen but I would rather put that work towards business logic


yes ... but the cljs sources and build related things don't need to be in there?


one deps.edn + shadow-cljs.edn per lamda seems incredibly clunky


The node_modules and build output have to but that's it


And it is clunky haha


When I mentioned a while back about wanting a better way to work with multiple shadow instances this is what I was asking about


And the lambdas can have separate deps so I am unsure how best to split the config


hmm did I recommend not having multiple shadow instances back then? since that seems entirely unnecessary here πŸ˜›


you can just always load all deps


the build output will only contain whatever you actually used


so unless you need different versions of the same package it is not a problem to always load everything


This is a very good point


Then I can pull everything up into a single config


FWIW I do this in shadow-cljs. all build configs in one shadow-cljs.edn and all deps in project.clj. then all the various output going to

πŸ‘ 4

I will put in some time moving all this around, thanks for the help


@thheller Thanks! I tried doing it but for some reason it didn't work, probably because I missed a turn somewhere. Eventually my setup had the workspaces app use an "#app" div just like my real app So I renamed it, and with some fiddling it seems to work now ^^;


ideally you would have a or .core or whatever namespace that handles all the initialization logic


and you already have [views/main-panel] so your UI is already separate


so your workspaces build just shouldn't include the main ns


and go directly to views


Is there anyway to force shadow-cljs to bind to I'm running shadow-cljs 2.8.83 and I'm my config is:

;; shadow-cljs configuration
  {:target :browser
   :output-dir "resources/dev/public/js/compiled"
   :asset-path "/js/compiled"
   :js-options {:variable-renaming :local}
   :modules {:app {:init-fn app.core/main}}
   :devtools {:http-root "resources/dev/public"
              :http-port 3449}}}}


bind what exactly? the 3449 server?


the shadow-cljs dev http server


or the main server at 9630?


(both should be binding to by default)


I'm not sure exactly, but I am not seeing it bound to

✦ ❯ netstat -tulpn | rg LISTEN                                                                                                                                                                                                                                                                                                                                                                                                              09:35:16(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0*               LISTEN      -
tcp        0      0  *               LISTEN      -
tcp        0      0 *               LISTEN      -
tcp        0      0*               LISTEN      1313/puma 3.12.1 (t
tcp        0      0*               LISTEN      -
tcp6       0      0         :::*                    LISTEN      472/java
tcp6       0      0         :::*                    LISTEN      472/java
tcp6       0      0 :::5355                 :::*                    LISTEN      -
tcp6       0      0 :::44179                :::*                    LISTEN      472/java
tcp6       0      0 ::1:3000                :::*                    LISTEN      1313/puma 3.12.1 (t
tcp6       0      0 :::3449                 :::*                    LISTEN      472/java
tcp6       0      0 :::3451                 :::*                    LISTEN      472/java
tcp6       0      0 :::9630                 :::*                    LISTEN      472/java


tcp6 0 0 :::3449 :::* LISTEN 472/java?


yeah, I thought that would have worked too. My work has a kind of complicated dev set-up and I am trying to get it to work on Windows + WSL. I have shadow-cljs running on WSL and I can connect to it when using localhost:3449 from Windows. But generally my work uses and has code set-up to handle our dev environment from the url *. (for info on And when I try to connect to shadow-cljs on Windows from it can't find it. I'm trying to debug this and see if it's because it's not listening specifically on The thought that led me down that path is because a rails webserver listening on port 3000 and bound to is able to be reached by on Windows.


hmm yeah the 3000 seems to have an extra listen on


I'm on windows/wsl too but never tried


seems to run fine when started in windows


Just a heads up, I've done some more testing on this using just node and both WSL and WSL2. With node, binding to port :: and behaves the same on WSL. IE They're both accessible from . However, in WSL2 (which is what I run) only is accessible from . So it looks like WSL2 is not correctly handling :: . Thanks again, talking to someone else running WSL really helped narrow this down.


hmm that makes sense. I'm not on wsl2


hmm also works fine for me when started in wsl?


I don't really know. the default is to listen on and thats I all pass into it


I'm not specifying anythings related to ipv4/6 or further


Ok it must be something on my end then. I just tried recreating the acme-app from, and again I could connect on localhost:8080 but not


Thanks for the help πŸ™‚


what’s the appropriate way to emit a compiler warning?