Clojurians Log v2

You mean constantly running it as a server? Or running it on a server to output compiled js?

i'm not sure i understand the question, but I think the second one? I'm just trying to figure out how to run my release code on a server basically, and I think i'm going to need to use depstar to do it maybe.

So I assume you have a java server for the backend and shadow-cljs for the frontend?

in that case you can just uberjar both of them and have the server serve the frontend

server is heroku, I think they have java buildscripts. i've been having trouble getting an uberjar set up correctly when i have tried!

I'd recommend trying to build it manually first before setting up heroku. Wrestling with building an uberjar and heroku at the same time sounds like a bad time.

at least doing so would help you pinpoint where you're having trouble with bundling an uberjar

@ajsnow2012 there is no such thing as deploying a "shadow app as a jar". the output shadow-cljs produces is javascript which no presumption about which server you are going to use. shadow-cljs itself is never part of the server and shouldn't be. its job is just building the output and staying out of your production environment completely.

so anything that is capable of serving static files is fine. I don't know heroku but I'd assume there is something to do that

I personally just build stuff locally and then copy the output to a static webserver

of course if you need anything server-side you can do that as well but shadow-cljs doesn't handle those parts. I use lein for that.

some of my coworkers got a delay on compiling since from saturday

and now when he tries to open the application, it never loads, only in incognito mode

anyone here had some issue like this?

I don't understand why he is having this issue

sounds like a cache issue? maybe a service worker?

he deleted npm_modules/, .shadow-cljs/

and installed it again

but it not worked

any thoughts on debugging this?

in "normal mode" he is having a 304

and in "incognito mode" he is having 200

sounds like a cache issue? maybe a service worker?

he does not have a cache in the browser

i don't know how to debug a "service worker" sorry

😞

first confirm that non is active

where?

in chrome devtools under Application

304 is something the server sends so make sure you are using the correct server. it is not something the client can produce without a service worker.

might be browser extension also

304 is fine but it does point to a cache issue

so maybe there is some old bad html cached somehow

I don't know what your actual issue is so I can't help much

> it never loads

is there an error in the console?

something must happen

no, only loads eternally

😞

strange that is happening for him and for another coworker but not with me

again. did you verify you are connecting to the correct server?

shut down shadow-cljs completely and open the page again

yeah,

incognito goes well

what server is this?

which shadow-cljs version is this?

he cleared the browser and the cache and everything and it went well

😞

2.11.14 => shadow-cljs

sorry to mess it but thanks anyway @thheller

🙂

Having trouble configuring a custom dev-http host. I have been using localhost:7000 so far to access my live-reloading page. I thought I might be able to better separate my different web projects (and their differing SSL requirements) by changing the default dev-http host, so I modified my shadow-cljs.edn to read:

:dev-http {7000 {:root "classpath:public"
                  :host "stucco"}}

:dev-http {7000 "classpath:public"}

but nothing is available at stucco:7000 . Am I misunderstanding something here? Do I need to configure something else for this to work?

I'm guessing your dns doesn't resolve stucco to localhost

nothing to do with shadow-cljs, it can't configure your dns

:host only does something if your machine has multiple ips so it knows which to pick but since it picks all by default that usually doesn't do anything

on macos I believe you can add stucco 127.0.0.1 so /etc/hosts

then it should be find with :dev-http {7000 "classpath:public"}

or I'm misunderstanding your problem if you already have that

http://foo.lvh.me:7000/ is typically useful too

that domain just points all subdomains to localhost by default

@thheller Thank you. That is probably it.