Fork me on GitHub
Jakub Holý (HolyJak)08:12:28

Would it be possible to make the websocket client URL configurable? According to it is derived from the app's URL in a fixed way. But I need a different protocol (wss), host, and port (443) to make it usable with GitPod.

Jakub Holý (HolyJak)08:12:47

Some details about GitPod and ports: In essence every port is exposed at a different host, as https://<port>-<unique host>:443 (I believe WS works over https so the https proxy between the app and the browser is hopefully ok...)


It is already configurable via :devtools {:devtools-url ...}

Jakub Holý (HolyJak)08:12:33

Awesome, thank you very much! So if my app is exposed at https://8181-myhost/ and the nrepl port at port 9630 is exposed via https://9630-myhost/ then I set :devtools-url , right?

Jakub Holý (HolyJak)09:12:21

it works! thanks a lot!


I’ve got a shadow-cljs project that builds a single page app using Reagent/Kee-frame. I’ve also got shadow-cljs config that compiles stories namespaces for use in Storybook.js. Since adding Kee-frame, I get this error when attempting to run build-storybook,

info => Using default Webpack5 setup
ERR! => Failed to build the preview
ERR! Module not found: Error: Can't resolve 'xmlhttprequest' in '/Users/me/app-frontend/public/js/stories'
64% building 14/14 entries 5634/5692 dependencies 987/1313 modulesERR! ModuleNotFoundError: Module not found: Error: Can't resolve 'xmlhttprequest' in '/Users/me/app-frontend/public/js/stories'
I’m assuming this is because Kee-frame depends on some packages that support both browser & server-side routing (Reitit by default I think), but I don’t think my base shadow-cljs build is going to pull the server-side dependencies in, given it targets the browser. Here’s my shadow-cljs.edn
;; shadow-cljs configuration

 [[reagent "1.1.0"]
  [kee-frame "1.3.2"]
  [arttuka/reagent-material-ui "5.0.0-0"]
  [garden "1.3.10"]]

 :dev-http {8080 "public"}
 :builds {:app {:target     :browser
                :output-dir "public/js"
                :asset-path "/js"
                :modules    {:main {:init-fn app.frontend.core/render!}}}
          :stories {:target     :npm-module
                    :runtime    :browser
                    :ns-regexp  "-stories$"
                    :output-dir "public/js/stories"}}}


If I npm install xmlhttprequest , then I get other “Module not found” errors, with fs and child_process


My Stories are pure component tests. They don’t depend on Kee-frame in any way. I suppose I’m wondering if there’s a way to exclude certain packages from the stories build? Maybe that’d be a hack though to some preferable way to handle what seems to be a pulling of server-side flavors dependencies.


@bdrillard Quick check, did you run npm install in your project before starting shadow and storybook?


Yep, I cleared out my node_modules, did an npm install, shadow-cljs release app stories and then tried to run storybook.


I was able to figure it out. I got my storybook build to succeed by including the following in my package.json,

  "browser": {
    "xmlhttprequest": false
Had to what the browser configuration does. Seems like directly excluding what is known to be a server-side module from codepaths that can be assumed to execute purely client-side can be considered a bit heavy-handed, but it worked.

👍 1
Michael Stokley17:12:41

how can i pass in an arbitrary alias when starting up shadow-cljs?


not supported. but you can instead just call clj directly with whatever alias you like. clj -M:whatever:foo -m shadow.cljs.devtools.cli watch app would be equiv to shadow-cljs watch app


(assuming you are talking about deps.edn aliases of course)

Michael Stokley18:12:29

i could also define the alias in ~/.shadow-cljs/config.edn and my project specific .shadow-cljs.edn would see the alias, is that correct?


oh wait. didn't I add something like :deps-aliases in ~/.shadow-cljs/config.edn?


let me check the code, can't remember 😛


indeed I did I guess. {:deps-aliases [:foo]} in ~/.shadow-cljs/config.edn

Lukas Domagala18:12:52

not sure if this is a shadow or cljs compiler question: i’m writing lots of cljs macros lately and they are a pain to debug, mostly because it seems there is no way to get any insights into the macro. is there any way to get println to work during the macro expansion phase? or is there some better way to see whats happening on the clojure side of things?


println works just fine during macro expansion. I typically recommend building macros in a CLJ REPL


I typically have a comment block such as this and eval it in the REPL until the output of the macroexpands looks like what I want


until it does I won't even have it used in a build. that comes after


remember that macros are pure CLJ code so shadow-cljs doesn't even need to be present to work on these


ie. a regular function you can call with a quoted form just like the macro would

Lukas Domagala20:12:41

ah, so it’s just my repl env that “eats” the println? I’ve got calva starting shadow and don’t see the macro println when I run it as a cljs eval. I can’t usually just run it from clojure, since I’m accessing the cljs analyzer env and need access to the other cljs namespaces, but your make-fragments function does look interesting! and it does make sense to only switch to cljs macros once I really really do need access to the other cljs analyzer stuff, thank you for that idea as well!


yeah it won't show up as part of cljs eval since the println happens during compilation


but it should arrive somewhere, maybe just the console where shadow-cljs was started

Lukas Domagala20:12:48

i thought so too, but it’s not there either. i’ll try starting it by hand and connecting then. i’ve been using line defs as println replacement, but that does take longer. but thanks a lot for making me think about my dev style again, cljs macros have been frustrating to work with, but it’s partly just shooting myself in the foot by switching env’s to early.