Clojurians Log v2
shadow-cljs
Since we passed to the ESM target, for both worker and the main app, we started experimenting a very strange behavior on development build, It happens with hot reload-but not only and my guess is related to some limit of ESM imports issued...; because after some hot-reloads or just simple refreshes, network requests start just pending on devtools (no connection ID assigned at all). After a several hours of research, we modified our nginx settings to just reset connection on every request (for avoid possible bug in chromium of handling dead connections or something) and also disabled cache. But it has no real effect because connections are just queued on browser tab. A fast workaround is just closing the tab (because it becomes like "corrupt") and open a new one until this happens.
with esm target build, the browser starts fetching each module separately, i don't know the real issue behind, this...
I suppose the eval loader thing from :browser could be done for ESM as well. really thought the browser would handle loading ESM properly and not make this a problem.
http2 probably also fixes this. if you have nginx in front anyway maybe try that?
i will try http2, but i think eval loader can be interesting for ESM
because initial load using current apprach, fetches 2500 files, and takes several seconds to do so, let see if http2 improves that but not pretty sure if the improvement can be comparable with the eval loader apprach
And looks like configuring https and http2 for localhost (for development) is not so easy...
because serving https on non-standard port (because of non-root enviroment) is not very compatible with ESM imports or at least it looks like
not quite sure what ESM has to do with any of this?
is the interaction of the browser with esm import
I'm kinda lost. not sure what you are talking about. in my head you have a nginx server serving the generated .js files, you configured a ssl cert there and it is using h2?
in my setup I have a caddy webserver running locally, with a domain that is just pointing to my local IP. I configured it so it automatically commissions ssl certs (using letsencrypt). that server either serves all the files or just proxies to other servers
I get something like this, i have read several stuff about this but nothing clear, right now trying to make an isolated playground
and what happens if you just open one of those failing .js files in the browser normally?
it opens OK
that error looks like happens when an import is used
and what is the import it is using?
like the /js/main.js file? should just have a bunch of import("./cljs-runtime/...")?
right. looks fine to me. dunno why that would fail in any circumstance
check your nginx conf I'd say
yeah, that is i'm doing
https://github.com/nginx-proxy/nginx-proxy/issues/1642#issuecomment-1656750074
in your project I assume most of those files compiled from npm related sources? do you have an estimate how many actual cljs namespaces you have?
we have huge cljs codebase
I think we have near 700-800 namespaces only on cljs
and a normal load (without worker, which adds other bunch of requests) loads near 1500 files
yikes
ok, looks like the keepalive fixes the https problem, thanks for the hint
does it also fix the load times?
i'm testing it right now, The load time is not the "problem", the problem is when tab just stops sending requests... and enqueues all and http transport for that tab just dies...
Still after several refreshes i get pending requests that never resolves...
strange. I have an idea that might reduce the number of requests dramatically
we have no experimented similar issues with :browser target but I don't know the reason. Maybe we the esm imports are broken on chromium
i have not reproduced the queued requests on firefox
LOL, my last discovery: I put a caddy on top of nginx just proxying all requests and let caddy handle https, and i'm unable to reproduce the issue (i need more testing because it happens randomly, but still interesting...)
I gave up on nginx for local stuff because of its weird websocket proxying behavior. caddy does that better 😛
yeah, but we have a nginx with some busines logic (resolving internally the aws s3 and other stuff) and having on local the "same config" as in production like enviroments helps a lot reduce errors. But yeah, I agree, nginx looks like behaving very strange and its config is a bit meh
jw, why does:
(require '["foo/bar$Sub"])shadow$bridge("@js-temporal/polyfill").$Sub$ rather than shadow$bridge("@js-temporal/polyfill").Sub in release builds? Presumably I'm doing something cheeky here, but I don't understand what quiteyes you can just add externs, doesn't matter one bit whether its on Temporal https://shadow-cljs.github.io/docs/UsersGuide.html#_simplified_externs
short answer: a bug. long answer: because you are using :external shadow-cljs will not be processing the JS code, and thus not collect "enough" externs information to find "Sub", but inference is supposed to fix that, but I guess this is never inferred properly. feel free to open a github issue.
Do you have enough information for GitHub or do you need more?
thats enough. Just can't do it right now and might forget otherwise 😛
Is there a workaround I can use so I can extend-protocol on the classes within? I've been getting by on doing (.-YearMonthDate Temporal) up until now, but extend-protocol isn't very keen on that.
Does adding an extern for Temporal do the trick?