Clojurians Log v2

https://github.com/thheller/shadow-cljs/commit/561d4990d4ee8bbdb50fad537b5e9c4cd32f96c4 this maybe? although I don't see how, unless you also changed your cypress version in this upgrade process?

basically that change was only relaxing requirements. as previously it would fail to compile

but I'm guessing if cypress does any kind of lazy loading via import() then it maybe goes async in a case where it didn't before?

my guess is in general would be async related. as in something goes async, but never fulfills its promise, calls a callback, etc?

Sounds plausible 👍 Is there are a way to temporarily disable dynamic loading in shadow to try it out?

you misunderstand the purpose of this. there is no dynamic loading happening at all ever. the point was to remove it, well kind of

but no, there is no way to get back to old behavior. but the build wouldn't have worked before this change anyway, so I doubt this is really related?

meaning that if shadow-cljs ran into a npm dependency before that tried to use import() it would hard fail with an error

now it doesn't

you didn't run into a hard fail. so that doesn't seem to be it

> unless you also changed your cypress version in this upgrade process?

did you?

Yes, that’s correct, we didn’t have failures prior

No, Cypress is the same as before

as in something goes async, but never fulfills its promise, calls a callback, etc?This looks almost like the problem I’m dealing with, now I need to figure out what’s causing it

does it always go to the same spot where it gets "stuck"?

Yes, that’s where I’m looking now 👍

Will keep this thread updated if I find anything specific

Thanks!

FWIW there is a way to find if any dynamic imports are used, because it is a bit suspicious it starting to fail with that shadow-cljs version

could be shadow misidentifying a code pattern and changing code it shouldn't

(->> (shadow/compile! :your-test-build {})
     (:sources)
     (vals)
     (filter #(= :shadow-js (:type %)))
     (filter #(seq (:js-dynamic-imports %)))
     (vec))

runs this over the REPL, e.g. npx shadow-cljs clj-repl. change :your-test-build to whatever your build id is

I'd expect that to return an empty vector, but maybe it doesn't?

Yes, empty

I suppose you could try a local shadow-cljs checkout and use a more recent version with the commit above removed? however that works in git 😛

or take the .class file from an earlier jar and put it into your classpath 😛

kinda suspicious you reported a commit that I expected to cause a lot of breakage, but haven't heard of a single one until now

I’ve spent a few more hours digging, and figured that Cypress’s cy.intercept() stalls network calls when combined with shadow-cljs 2.26.6+, js/fetch never gets resolved/rejected. I guess the next step would be to check how they have implemented cy.intercept() and why it clashes

not sure what that is, so can't say much

Actually, scratch that. We might have done something weird in the way we’re intercepting loading of all resources. including js. Might be a user error in the end! Thanks for the support 🙏

still doesn't explain why it would break only when changing shadow-cljs version? 😛

I’ll check again but I think all js urls were accidentally intercepted, and maybe this could have made loading to become very slow? I’ll have to look into the exact mechanism how network requests are intercepted there