figwheel-main

jrychter 2022-12-12T10:17:56.903069Z

Ok, so this is totally bizarre and I have no idea what is happening. Removing this (unused) dependency from my project.clj breaks figwheel-main. Specifically, it stops recompiling and reloading code upon changes.

-                 [com.cognitect.aws/api "0.8.603"]
It's a big app. I've spent hours bisecting the changes to get to what exactly started causing this problem, and this is it. Reverting this commit makes figwheel-main work again. In other words, I need to keep this in so that figwheel-main works. Things I tried: I removed the entire .m2/repository tree, checked lein deps, even tried a newer version of clojure.data.xml since com.cognitect.aws/api seems to want org.clojure/data.xml "0.2.0-alpha8". Nothing matters, except whether this dependency exists in my project.clj. Again, this isn't actually used anywhere. It was sitting in my project.clj for years, before I migrated from figwheel to figwheel-main. I am leaving it in for now, just so that I'm able to develop. If I remove the dependency, figwheel-main will do the initial compile as normal, and then on the first change (but only on the first one) it will say again: [Figwheel] Compiling build dev to "target/public/cljs-out/dev-main.js" . In spite of this message, the change will not be reloaded and manual reloading will not load the changed code, so it seems the compile doesn't actually happen. I also don't get any of the browser debug messages in clj console. I'm out of ideas — any hints/suggestions?

bhauman 2022-12-13T19:49:59.344209Z

@jrychter Unfortunately, figwheel-main uses jetty for its communications to the front end. They way jetty manages its packages kinda sucks https://figwheel.org/docs/jetty_conflicts.html

bhauman 2022-12-13T19:51:46.574919Z

sorry for the impact here. I really regret moving to jetty from http-kit, my reasoning at the time was very flawed.

eskos 2022-12-12T10:25:21.295459Z

Sounds like you’ve been (accidentally) relying on a transitive dependency. Or figwheel-main is. The unfortunate possibility is that since figwheel-main uses deps.edn, it might rely - equally by accident - on deps.edn’s Maven incompatible resolving logic, which means it’s impossible to have a proper conflict free resolution for tools which actually use by-the-spec https://wiki.eclipse.org/Aether/What_Is_Aether resolver. I’ve had a similar transitive dependency resolving issue with Lacinia from deps.edn, and the most reliable way to solve that was to simply trust the magic of adding the transitive dependency explicitly into my project with comments around it in all caps explaining that it just needs to be there.

eskos 2022-12-12T10:28:36.648539Z

If you’re up for it, you could try to figure out the exact culprits with analysis of the lein deps :tree output and comparing that with what’s defined in figwheel-main’s https://github.com/bhauman/figwheel-main/blob/master/deps.edn and what that project ends up resolving…

jrychter 2022-12-12T10:43:46.543939Z

Hmm. aws/api has a pretty short list of dependencies:

[com.cognitect.aws/api "0.8.603"]
   [com.cognitect/http-client "1.0.115"]
     [org.eclipse.jetty/jetty-client "9.4.48.v20220622"]
     [org.eclipse.jetty/jetty-http "9.4.48.v20220622"]
     [org.eclipse.jetty/jetty-util "9.4.48.v20220622"]
Figwheel-main's dependencies related to jetty do not seem to overlap:
[org.eclipse.jetty.websocket/websocket-server "9.4.36.v20210114" :scope "test"]
     [org.eclipse.jetty.websocket/websocket-client "9.4.36.v20210114" :scope "test"]
     [org.eclipse.jetty.websocket/websocket-common "9.4.36.v20210114" :scope "test"]
     [org.eclipse.jetty/jetty-servlet "9.4.36.v20210114" :scope "test"]
       [org.eclipse.jetty/jetty-security "9.4.36.v20210114" :scope "test"]
       [org.eclipse.jetty/jetty-util-ajax "9.4.36.v20210114" :scope "test"]
   [org.eclipse.jetty.websocket/websocket-servlet "9.4.36.v20210114" :scope "test"]
     [org.eclipse.jetty.websocket/websocket-api "9.4.36.v20210114" :scope "test"]

jrychter 2022-12-12T10:45:20.186399Z

And my entire app doesn't use jetty — I use http-kit with a managed [io.netty/netty-all "4.1.42.Final"] dependency.