This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-04
Channels
- # announcements (7)
- # beginners (37)
- # boot (6)
- # calva (13)
- # cider (13)
- # cljdoc (52)
- # cljs-dev (9)
- # clojure (117)
- # clojure-europe (3)
- # clojure-italy (12)
- # clojure-nl (21)
- # clojure-russia (8)
- # clojure-spec (77)
- # clojure-uk (20)
- # clojurescript (142)
- # community-development (6)
- # cursive (5)
- # datomic (13)
- # emacs (9)
- # figwheel-main (20)
- # fulcro (33)
- # graphql (11)
- # instaparse (6)
- # klipse (1)
- # off-topic (7)
- # om (8)
- # quil (7)
- # re-frame (11)
- # reagent (39)
- # reitit (10)
- # shadow-cljs (36)
- # spacemacs (3)
- # test-check (3)
- # tools-deps (83)
- # utah-clojurians (31)
- # vim (14)
Is there some example project which uses shadow-cljs with leiningen instead of shadow-cljs with npm?
@kwcharllie379 do you mean completely without npm or just managing dependencies with lein
?
I would like to manage dependencies with lein and also be able to attach dirac agent
Is there way to attach it somehow? via repl-options?
Or should I stick to devtools for now?
It’s just a clone of devtools https://github.com/binaryage/dirac
hi, maybe I could shed some light on it, dirac agent is non-issue, it is just a proxy between nrepl server and dirac’s client in web browser, the problem is nrepl middleware responsible for translating clojurescript to javascript on server side, shadow-cljs uses their own middleware (originally forked from piggieback), dirac uses their own middleware - dirac would have switch using shadow-cljs middleware for this job
I guess I had a similar issue with figweel, I wanted to use it’s cljs compiler state to drive evals of cljs code coming from dirac REPL
@darwin what do you actually need for dirac though? I'd expect that access to the compiler env is enough?
we would have to do something along these lines: https://github.com/binaryage/dirac/blob/master/docs/about-repls.md#dirac--figwheel
not quite sure why you doing all this nrepl mess when you are running something in the same VM already
(diract.agent/boot! {:eval-fn ... :env compiler-env-atom})
seems to me like it would be
just correction, I wanted to write that dirac middleware was forked from piggieback, did a wrong edit there ^ 🙂
not sure why the whole nrepl stuff is necessary but I honestly don't know at all what you do so you probably have your reasons 🙂
I don’t remember the reasons, but the thing was created without prior design incrementally, the figwheel support was added later
I started with piggieback + nrepl proxy (dirac agent) until I realized it won’t work in some cases and then I needed to rewrite it
dirac agent does not necessary need to run inside the same JVM, only nrepl middleware has to
btw. here it the high-level code responsible for eval: https://github.com/binaryage/dirac/blob/master/src/nrepl/dirac/nrepl/utils.clj#L121 I need cljs compiler which is either normal cljs or figwheel, compiler env is part of nREPL session state I believe (same what piggieback does)
https://github.com/binaryage/dirac/blob/master/src/nrepl/dirac/nrepl/utils.clj#L133 here is the dirty job: https://github.com/binaryage/dirac/blob/master/src/nrepl/dirac/nrepl/eval.clj#L219 I don’t remember why it has to be so complex, but it had to be for some reason