things were working properly for me, and then suddenly i started getting this error message

i didn't know what i changed to cause it, i tried reloading the page, restarting browser, restarting repl, restarting shadow-cljs, restarting my machine

nothing seemed to work

i also tried clearing cookies/localstorage for localhost

one clue was that a private tab DID work

(i'm using brave)

finally i tried deleting the compiled app.js

verified that i got a 404 when i loaded the page

then got shadow-cljs to rebuild it

and now...it works again

anybody have any idea what the problem might have been?

the behavior seems possibly consistent with the page being cached in the browser (and private tabs ignoring the cache?), but i'm still not sure why things were working for several days before i hit this issue

a friend suggested disabling the cache in the developer console:

do you use the built-in :dev-http server or some other http server?

the built-in sets the proper cache headers so this doesn't happen. otherwise it might be cache related

or you might have a service worker

don't know enough about your setup to say more

the problem could also be caused by having shadow-cljs running twice in the same project

basically interfering with each other

i'm using kit, which bundles undertow

now that i think about it, does my caching explanation even make sense? why would deleting app.js even cause a 404 in the console if it was cached?

i don't know what a service worker is

i did check for multiple shadow-cljs since you mentioned that to other people...restarting my machine and starting everything fresh should rule that possibility out

if you don't set your caching headers I don't think any are set by default. which will not be ideal with regards to caching

but the network log should show whether it used a cached version or not

maybe brave does some weird caching on its own. can't really say.

i'm new to all this so i don't know how to check the caching headers in the response, but i'm very curious myself

presumably there's some debug option i can set to get kit/undertow to print the response somewhere? (i will look into this more myself when i get a chance)

the network log is a good idea, i'll check that next time i hit this problem

just check the network tab for the request for your .js file

if served via :dev-http it has the Cache-Control: private, no-cache header

and the response will either be a 200 or a 304 not modified

no need to check kit/undertow. the browser network thing will tell you everything you need to know

ahhh, very handy!!

the response doesn't have any cache control headers

btw is it normal to see two of these "remote-relay" requests?

yes, thats the websocket connection for hot-reload/repl

dunno why there is two but one is done so maybe it got reconnected? maybe computer sleep?

ok, i only mentioned it in case it might be related to the issue was having, sounds like it's fine

I think I figured it out, was missing the following:

window["$CLJS"] = require("./npm-module/cljs_env");
require("./npm-module/shadow.cljs.devtools.client.browser");

window["$CLJS"] = require("./npm-module/cljs_env"); this you shouldn't do. it won't work in a release build in case you use it for anything

this is caused by a dependency conflict on the guava dependency. the closure-compiler doesn't properly declare it so it gets messed up

Oh thanks. I forced guava to the latest version (`31.1-jre`) and it worked. > the closure-compiler doesn't properly declare it so it gets messed up Indeed, I couldn't find guava as a dependency of shadow using clj -X:deps tree | less

yeah, fix is in process https://github.com/google/closure-compiler/pull/3935

@U3ZG4CAF8

All, fix is to explicitly add

com.google.guava/guava {:mvn/version "31.1-jre"}