This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-22
Channels
- # announcements (2)
- # beginners (42)
- # calva (2)
- # cider (13)
- # clara (2)
- # cljdoc (1)
- # cljs-dev (8)
- # clojure (118)
- # clojure-australia (1)
- # clojure-europe (3)
- # clojure-finland (2)
- # clojure-italy (42)
- # clojure-japan (1)
- # clojure-nl (2)
- # clojure-spec (26)
- # clojure-uk (58)
- # clojurescript (83)
- # cursive (6)
- # data-science (2)
- # datomic (13)
- # devcards (2)
- # duct (9)
- # figwheel-main (4)
- # fulcro (11)
- # graphql (51)
- # jobs (1)
- # juxt (14)
- # kaocha (1)
- # off-topic (24)
- # re-frame (65)
- # reagent (4)
- # reitit (19)
- # remote-jobs (8)
- # shadow-cljs (50)
- # specter (3)
- # speculative (1)
- # vim (5)
- # yada (50)
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
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 -
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.