Any plans to migrate from figwheel/figwheel-sidecar to figwheel-main?
I'm going to look into that, and shadow-cljs as options... when I have time 🙂
But yes, in theory migrating to figwheel-main sounds like a good idea.
I think I agree. We’ve had some problems after upgrading to leiningen 2.8.3; with piggieback transitively included via duct/server.figwheel
not sure on all the details tbh but adding
:profiles {:repl {:dependencies [[cider/piggieback "0.3.10"]]}
to override piggieback seems to have fixed it… though not entirely sure how.
Stacktrace is:
$ lein repl
See <https://github.com/technomancy/leiningen/wiki/Repeatability>
Warning: replacing existing support for s3p repositories (user$eval497$fn__498@796d3c9f) with user$eval505$fn__506@6bff19ff
Warning: replacing existing support for s3 repositories (user$eval501$fn__502@5eccd3b9) with user$eval509$fn__510@4d6f197e
Warning: implicit middleware found: lein-duct.plugin/middleware
Please declare all middleware in :middleware as implicit loading is deprecated.
[WARNING] No nREPL middleware descriptor in metadata of #'cemerick.piggieback/wrap-cljs-repl, see nrepl.middleware/set-descriptor!
nREPL server started on port 56604 on host 127.0.0.1 - <nrepl://127.0.0.1:56604>
ERROR: Unhandled REPL handler exception processing message {:id 5cc81f91-f1d6-4657-91a6-9d6545409323, :op clone}
java.lang.NullPointerException
at clojure.core$deref_future.invokeStatic(core.clj:2300)
at clojure.core$deref.invokeStatic(core.clj:2320)
at clojure.core$deref.invoke(core.clj:2306)
at cemerick.piggieback$wrap_cljs_repl$fn__2520.invoke(piggieback.clj:289)
at clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__2116.invoke(middleware.clj:22)
at nrepl.server$handle_STAR_.invokeStatic(server.clj:18)
at nrepl.server$handle_STAR_.invoke(server.clj:15)
at nrepl.server$handle$fn__1080.invoke(server.clj:27)
at clojure.core$binding_conveyor_fn$fn__5730.invoke(core.clj:2030)
at clojure.lang.AFn.call(AFn.java:18)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Should I create an issue on duct/server.figwheel?
I've just taken a look through figwheel-main. I think I'll need to ask the author some questions, as it's not obvious if it's possible to manually control the rebuilding process without hooking deeply into the internals.