This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (240)
- # boot (23)
- # bristol-clojurians (3)
- # cider (101)
- # cljs-dev (52)
- # cljsrn (17)
- # clojure (212)
- # clojure-dusseldorf (2)
- # clojure-greece (2)
- # clojure-italy (9)
- # clojure-russia (1)
- # clojure-spec (91)
- # clojure-uk (33)
- # clojurescript (164)
- # community-development (23)
- # core-async (24)
- # core-logic (9)
- # cursive (18)
- # datavis (1)
- # datomic (119)
- # emacs (13)
- # events (1)
- # figwheel (2)
- # fulcro (86)
- # graphql (1)
- # immutant (5)
- # jobs-discuss (6)
- # leiningen (19)
- # lumo (46)
- # nyc (7)
- # off-topic (23)
- # parinfer (15)
- # pedestal (3)
- # planck (32)
- # re-frame (48)
- # reagent (75)
- # ring-swagger (13)
- # rum (32)
- # shadow-cljs (402)
- # spacemacs (5)
- # specter (3)
- # tools-deps (11)
- # unrepl (20)
- # vim (135)
- # yada (3)
do i understand that output from threads other than the main thread can go to the nrepl buffer? if I read from a socket on another thread (which is handled by the Jetty websocket library), then any logging that socket read does would go to the nrepl buffer?
@bozhidar you talked about removing gradle. how would I go about adding
shadow-cljs? it supports injection via
shadow-cljs -d cider/cider-nrepl:0.16.0 server?
> do i understand that output from threads other than the main thread can go to the nrepl buffer? if I read from a socket on another thread (which is handled by the Jetty websocket library), then any logging that socket read does would go to the nrepl buffer? At least when dealing with Clojure - what ends up in the nrepl buffer is output that got bound to the server’s stdout/stderr. We’ve got some logic to redirect this to the REPL buffers, so people won’t miss it, but I’m not sure what exactly’s going on in your case.
@thheller So, you don’t need
boot or something like this? You can just spin the nREPL server with all the deps using the
And I assume the resulting connection is a cljs connection, which is directly ready to be used?
We’ll need some way to know we’re in a shadow-cljs project. Is there some file marker we can rely on?
OK, so all of this is going to be very easy. I can hack it together myself if you’re afraid of Elisp. 🙂
The only open question is how to convert the resulting repl to cljs - I was told there’s not fixed code snippet you can execute, as you had to pass some project-specific build id.
It’d be nice to have some easy way to spawn a cljs repl without having the user to type anything themselves.
yes shadow-cljs supports multiple builds and you can "select" which REPL you want to talk to
We don’t currently use it, but a parser was implemented recently so we can leverage it.
to switch the nrepl connection to this build you'd first call
(shadow.cljs.devtools.api/watch :app) to start the "worker" which will recompile and all that jazz
(shadow.cljs.devtools.api/nrepl-select :app) to switch the current nrepl to this build and turn it into CLJS
I could add additional helper fns/middleware that lets you query which builds exists and so on
ah I guess this is the relevant code. https://github.com/clojure-emacs/cider/blob/master/cider.el#L547-L563
so the quickfix would be to add a no-args version that just picks a "default" build. which is easy it there is only one.
@bozhidar you can run multiple
(shadow.cljs.devtools.api/watch :build2) in parallel. they run in the background.
(shadow.cljs.devtools.api/nrepl-select :build1) switches to CLJS of build1.
:cljs/quit switches back to CLJ, then call
nrepl-select again to switch to either
alternatively you could just call
(shadow.cljs.devtools.api/browser-repl) which starts the browser repl, opens a browser, and switches the REPL to CLJS
well technically its just one type, the
node-repl are just utility fns to just quickly spin up a REPL without having to configure a build first
it sounds like shadow-cljs works the way we want piggieback to eventually work: with suspendable cljs repls in a single repl
maybe make a new workflow for shadow cljs and then migrate piggieback to work like that. without a sibling repl
I’m interested it trying it, and I’ll document it in shadow if someone doesn’t beat me to it.
Let me finish reading the guide, and then I’ll be ready to try it. What’s the quick start so far to connect cider to nREPL with shadow?
@jmckitrick easiest currently should be to run
shadow-cljs server externally in a terminal and use
cider-connect to connect to it
It looks like I’m connected, but
op "info" via cider-nrepl. So I probably needed to start something else first….
So I assume I need to pick through my lein dependencies and copy the cljs ones into the shadow.edn to start @thheller
you can also specify
:lein true and just run
@dpsutton We’ve been hearing a lot about new user experience, so this is good to hear.
cider-connect and I have a REPL running. How do I tell cider to begin using this connection for
> it sounds like shadow-cljs works the way we want piggieback to eventually work: with suspendable cljs repls in a single repl
I was looking at a coworker of mine who uses intellij's screen yesterday, and saw that apparently his setup puts unused variables (as in, introduced in a let, but then never actually referenced) in a different color; is there a way to do something similar in cider?
I don’t think you can suspend and resume a cljs session with shadow-cljs, but I might be mistaken. At any rate - @bhauman’s latest idea about piggieback would make this irrelevant (most likely), as it would enable using one REPL for both clj/cljs without the need for a second connection at all. I think everyone would agree that’d be quite handy. 🙂
@tanzoniteblack CIDER itself doesn’t support this, but it’s doable. clj-refactor might have some functionality for this, not sure about that.
@bozhidar it can suspend and resume
[email protected]:.../shadow-cljs$ shadow-cljs cljs-repl browser [5:1]~cljs.user=> (def x 1) #'cljs.user/x [5:1]~cljs.user=> :cljs/quit [email protected]:.../shadow-cljs$ shadow-cljs cljs-repl browser [6:1]~cljs.user=> (inc x) 2 [6:1]~cljs.user=>
@bozhidar I’m willing to help with the cider/shadow integration. I have it working locally. Or have you already started?
I haven’t started, but it’s probably best for me to do this, as I already know exactly what needs to be done. But if you do it by tomorrow morning that’d be fine by me - I’m already super busy as it is. 😄
@thheller piggieback also has
:cljs/quit but I think this wipes the cljs session clean, therefore the conversation about adding
I do think that this is pretty important, though, so I’ll try to do it as soon as tomorrow.
if all supported cljs sessions are suspendable, we could more mimic shadow-cljs. That's why i was saying there might be some benefit in making a custom
jack-in-shadow-cljs and then making the current piggieback workflow work like that. and then unify them into a
cider-jack-in-clojurescript with a single repl
What exactly would be special about jack-in-shadow? After all apart from running different commands you’d be doing exactly the same thing as for piggieback - you start a clj repl and evaluate some expression in it to convert it to a cljs repl. The only difference I see is that with shadow we’ll know definitely in advance what type of REPL to start - with piggieback you can never know if the users wants rhino, nashorn, node, etc. If they have a figwheel dep that’s probably what they want, but you can never be certain. Same for weasel.
so if those mechanics work, if we get piggieback to be suspendable and not require a separate repl, all the other workflows would naturally just then be configuration in the shadow jack in workflow
what if I start build for
:build1 then pause it, start
build2, pause that. how do I get back to 1 without going through 2
Yeah, yeah. But those details are not a big deal in the end of the day. To make what you say work we’ll also have to add provisions to all eval commands to toggle the repl type depending on the type of the source buffer (.clj or .cljs). I’m also wondering what are we supposed to do when evaluating code from a .cljc file. Now it’s easy - we send it to both REPLs, but if there’s just one I guess we have to decide if we want to run the clj code, then the cljs code and the quit cljs for each expression.
> Now it’s easy - we send it to both REPLs, I don't like this and I want to remove it
That’s why I generally prefer the idea of being able to send the code type as a parameter to
eval - makes of this “magic” redundant.
we could have
cljs/pause as an nrepl op. returns on message with some kind of identifier. then another nrepl op