Fork me on GitHub
#shadow-cljs
<
2021-10-04
>
flowthing05:10:52

I currently rely on shadow.cljs.devtools.server.repl-impl/do-repl in the (experimental) shadow-cljs support for an editor plugin I'm working on. I realize that it's not part of the stable API, though. Would it be possible to have it be a part of the API (e.g. in shadow.cljs.devtools.api)? I'd be perfectly happy with something that basically just defers to shadow.cljs.devtools.server.repl-impl/do-repl without doing anything else.

thheller05:10:19

@flowthing what exactly are you doing with do-repl? I mean that is pretty REPL specific and most likely and editor should be talking directly to shadow.remote? That isn't documented much yet but the basic concept is explained here https://github.com/thheller/shadow-cljs/blob/master/doc/remote.md

flowthing05:10:59

My editor plugin connects to the shadow-cljs socket REPL and starts a slightly customized prepl-like REPL on top of it. It also opens a socked-based backchannel, which the editor plugin then connects to to send tooling messages back and forth. I'm aware of shadow.remote, but I only really want/need a REPL.

thheller05:10:02

but if you connect to shadow.remote directly you get all of the REPL functionality + the potential of all other editor tooling over one connection

thheller05:10:38

I mean all the shadow-cljs REPLs are built on shadow.remote as well as everything the UI does

thheller05:10:56

eventually everything that is not currently using it will be using it internally. eventually the intent is for all tools to use it too. I mean even do-repl uses it internally

flowthing05:10:44

Right, but I want to retain the ability to start nested REPLs, for instance. Also, I specifically want to send evaluations and tooling-related messages over different channels.

thheller05:10:47

do-repl will not become part of the public API but if you explain what exactly you need from it I can maybe adopt the shadow.cljs.devtools.api/cljs-repl?

flowthing05:10:16

> I mean even do-repl uses it internally Hmm, so maybe I could reimplement something like do-repl over shadow.remote. :thinking_face:

thheller05:10:30

there is no support for nested REPLs for any CLJS REPL or anything using do-repl?

thheller05:10:23

do-repl is running over shadow.remote already so anything it does you can replicate

flowthing05:10:12

Oh, right! I've been away from the CLJS side of things for a while so I forgot about the nested REPLs. Anyway, reimplementing the relevant bits of do-repl over shadow.remote sounds like the way to go. Thanks! I might be back with possible questions regarding shadow.remote. 🙂

Björn Ebbinghaus10:10:02

Today I noticed again, that shadow-cljs didn't stop compiling my project over and over again in the background, and I was not modifying any files (at least to my knowledge) I notice this from time to time, and a restart of the server is enough to solve the problem. Has anyone had similar experiences? It's not a big problem (when I notice it), and I can't rule out that it's not my IDE or some plugin that keeps changing things. Mostly I notice it when my Mac stops turning off the fan. 😕

eins7815:10:53

we had such a case in our setup, maybe it happens in yours too: we were watching (JS inside the) the output-dir, leading to an endless compile-loop.

thheller17:10:35

yeah definitely keep the output-dir out of the source paths

thheller17:10:56

but otherwise most of the time its some other tools touching files and kicking off compiles

thheller17:10:27

you can set :log {:level :debug} in your shadow-cljs.edn and it'll log a little more including the namespaces/files that triggered a compile