@thheller thanks. Have set that flag, and also :autoload and :ignore-warnings to true: https://github.com/thisdotrob/shadow-cljs-node-hot-code-reload

but it still isn't running the hooks :white_frowning_face:

@rs works for me?

__filenamex /mnt/c/Users/thheller/code/shadow-cljs/tmp/shadow-cljs-node-hot-code-reload/out/demo-script/script.js
starting server
http server running
stop called
stop completed undefined
__filenamex2 /mnt/c/Users/thheller/code/shadow-cljs/tmp/shadow-cljs-node-hot-code-reload/out/demo-script/script.js
start called
starting server
http server running

My bad, didn't realise you still had to run the script separately with node!

I was trying to replicate my other shadow-cljs project's setup which starts serving up a re-frame app straight automatically after compiling, but for node-script. More investigation needed

well if its re-frame you probably open it in a browser?

node script you need to run manually yes

Yep open it in a browser, but I have :http-root and :http-port so it is being served up automatically after compiling

was hoping to have a similar setup for my node server, with it starting automatically

perhaps this is beyond the scope of shadow-cljs' responsibilities though

@rs nothing starts automatically with a browser app. you need to open it otherwise nothing else happens. the http server literally just serves files nothing else.

node server starting is out of scope yes since you may need stdin or just want a CLI script to exit

you can always use shadow-cljs node-repl and do things manually but it won't execute hooks

@thheller I’m trying to get started with a local fork of shadow — are there any more instructions than CONTRIBUTING.md ?

@orestis depends on what you want to do?

I want to diagnose and try and fix https://github.com/thheller/shadow-cljs/issues/422

don't need a local fork for that

I want to tweak the way that shadow injects the hud.

you can just put this file into your classpath https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/devtools/client/browser.cljs

Oh, that’s neat.

that should override whatever shadow-cljs ships

might need this too https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/devtools/client/hud.cljs

I can probably fix this if you provide a full stacktrace

no idea how to get it in ie11 but I'm pretty sure there is a way to get it

Unfortunately IE11 on a VM isn’t exactly user friendly in that regard 🙂

But let me see.

yeah ie11 has horrible dev tools but I think the console still shows a trace

shadow.dom.append.cljs$core$IFn$_invoke$arity$2 [Line: 867, Col: 1], shadow.dom.js
shadow.cljs.devtools.client.hud.dom_insert.cljs$core$IFn$_invoke$arity$2 [Line: 360, Col: 1], shadow.cljs.devtools.client.hud.js
shadow.cljs.devtools.client.hud.dom_insert.cljs$core$IFn$_invoke$arity$1 [Line: 342, Col: 1], shadow.cljs.devtools.client.hud.js
shadow$cljs$devtools$client$hud$connection_error [Line: 770, Col: 1], shadow.cljs.devtools.client.hud.js
Anonymous function [Line: 1038, Col: 1], shadow.cljs.devtools.client.browser.js

ah perfect

This is what I see in the “call stack” — unfortunately not source-mapped.

so it fails to connect to the shadow-cljs server I guess

connection-error is trying to display a warning and that fails

I don’t think that’s it — my hunch is that body is not available yet when I load my code.

shadow$cljs$devtools$client$hud$connection_error is pretty clear in what it does 😉

Ah, cool — yes, it wouldn’t be able to do the connection because it’s running in a VM.

But still the hud is the one breaking, right?

you could run shadow-cljs compile your-build

that won't load the hud and stuff, so it can't error out on startup

or you can set :devtools {:devtools-url ""}

if the VM can connect to that server

I might need to proxy that shadow websocket anyway, because then things like browserstack can never work. I want to get my designers a way to see their changes live on many different browsers.

ok then you need to figure out why the websocket fails connecting

Still though, I think the fact that hud/dom-insert is using js/document.body is a little smelly 🙂 I’ll see if I can tweak that to make sure the error reporting works.

its bad that it fails to show that error but thats not causing the error

it can't show the error if there is no document.body 😉

Yes, of course — this is caused because I load my CLJS in head (long story, unavoidable unfortunately). Many things break 🙂

It’s funny how most of us now assume that JS is going to be loaded at the end of the body element.

head is not the issue here

all of this happens async. I don't know why IE11 even attempts to connect while body is not present

its supposed to finish loading first

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/devtools/client/browser.cljs#L397

I’m trying to override hud.cljs. I’ve placed it right in my source path, path is <source-path>/shadow/cljs/devtools/client/hud.cljs but my changes don’t seem to have any effect. Am I doing something wrong?

probably need to restart the server process if that is still running (ie. watch)

Regarding the timeout thing, I see here: https://github.com/thheller/shadow-cljs/blob/9752ddcf0502b559ccae66389f4e61e7d13bbd7c/src/main/shadow/cljs/devtools/client/browser.cljs#L371-L374

So the moment this the websocket error happens, the hud tries to show the connection error and then blows up.

What would be the downside of replacing the setTimeout to a DOMContentLoaded event?

did ie11 have domcontentloaded? can't remember

but yeah that would be fine by me

Ok, replacing files works, I’ll have a look about replacing that and report back.

Perhaps there’s a Google Closure way to do this safely.

Is there a minimum browser version for shadow?

dunno. not sure I want to support ancient browsers. I hate ie11 enough for work I don't really want to deal with it elsewhere 😉

DOMContentLoaded goes back to IE9.

ok definitely not interested in supprting ie8 😉

What about sth like: (if js/document.body (current-behaviour) (try-later))

this would be replacing the existing (js/setTimeout (ws-connect))

Still though, seems off to delay connecting the websocket until the document is ready.

no it should always be async

so other load events can fire first

OK, I’ve got this working — on to the next hurdle: getting a relative :devtools-url to work. It seems the code in env/ws-url expects a full url because it tries to replace http with ws.

I’d like to have my devtools-url be /shadow-cljs-server so that it goes to whatever the serving address is…

it defaults to using the url you load the page from

since that is usually what you want

it must be a full url since its needed for ws and xhr requests

Ah, what about if I want to keep the host the same but use another port?

that is the default?

whoops, sorry, reuse the same port and host. So my webserver is responsible to proxy the traffic.

Just to clarify: I’m loading my page from . I want to instruct shadow to connect to . But I’m also loading my page from , so I want then the connection to be

I’ll make a PR for all this, BTW.

Hm, replacing env.cljs doesn’t seem to take any effect. I wonder if all the google-closure defines at the top have anything to do with it.

I need to break for lunch but I’ll be back 🙂

need to restart the watch/server to replace the file I guess

Yeah, I did that for the other cases but env.cljs is stubborn…

What a wild goose chase. Turns out the default behaviour of shadow is just right — it’s trying to connect to “whatever-host-you-have:9630” which should just work for all my use cases. But, IE11 inside that VM complains with: SCRIPT12008: WebSocket Error: Incorrect HTTP response. Status Code: 200, OK

it shouldn't answer with that though? should get an upgrade response? is a proxy or something active?

This is definitely IE11 specific. Chrome inside that VM is working correctly with the default shadow settings.

I suspect something about security things but I’m not quite sure how to troubleshoot this.

To clarify: shadow’s default that connects to ... works just fine when using chrome inside a VM and safari outside the VM, where original-host is different. It’s only IE11 that complains with that cryptic error.

no idea what it might do differntly

I give up. IE11 on windows 10 manages to connect succesfully. Funnily enough, there, reloading only works with dev tools open. Otherwise I get a shadow hud saying: [reload failed] invalid calling object

If I open the dev tools, then reload works as expected.

I’ll update my issue with all this info, and a PR for the websocket connection on document load.

Thanks for the guidance!

@orestis I had one of those issues with IE before. forgot the details though. something to do with standards/quirks mode

Highly probable.

All I want is my designers to be able to quickly preview CSS/markup changes on both IE11 and modern browsers. Having the devtools open is not a deal breaker for this, so I’ll stop exploring for now.

I’ve opened a PR for this. Thanks for all the help and for shadow itself 🙂

I wonder, is that barrage of document.writes something that shadow-cljs controls? Or does it come from some lower level?

I mean, the loading of the various clans-runtime stuff when in development mode.

It makes working with browserstack (where the VM running the browser is far away) a tad painful.

@orestis you can set :devtools {:loader-mode :eval}. should make things faster.

Thanks!

Have you considered having a patreon page or re-applying for Clojurists together? Your work is hugely important :)

I have and I will. Just didn't have time this cycle