You mean https://clojurescript.org/community/companies ? Oh what projects do you mean exactly?

https://clojurescript.org/guides/project-templates for example

https://clojurescript.org/community/libraries als lists stuff that is no longer maintained such as Om

I wouldn't change anything. Those libraries that exist, are written in ClojureScript, and work. http://clojurescript.org is one, the libraries are many - maintaining flags for each an every one is unfeasible IMO.

Sure they work, but wouldn't you want to direct people to the good stuff... Clicking through and seeing a bunch of deprecation notices makes the ecosystem seem pretty dead.

How do you define "good stuff"? In the Clojure world, there's a lot of properly working libraries that haven't received a single change in years, because they just work. Some of them are even archived on GitHub - again, because there's nothing to fix, nothing to add, nothing to change.

A project that straight up tells you to go use something else is a pretty low bar to clear.

Issues and PRs are welcome! https://github.com/clojure/clojurescript-site

I agree the website could use updating of links and guides, there is a repo somewhere to issue PRs to do updates, if you've been away for a couple of years, then check out clj-kondo, figwheel-main, shadow-cljs, reframe/reagent are still quite good for React

Just because there's dust somewhere in my house doesn't mean that nobody lives there or even that nobody maintains it. :)

Thanks 🙂 yea I eventually made it from the deprecated figwheel to the maintained one, which seems pretty lively.

I get no js runtime errors in shadow cljs until i go to page im browser. Localhost:8080. Then it works

What @U013YN3T4DA says. Do you have the app running in your browser or simulator/device?

if you’re running the literal Node REPL then it should automatically start the runtime, but it might depend on how you start it. cant’ quite remember the details

if you’re running a node-script build, then you’ll need to start the node script as a separate process

what exactly are you trying to REPL into? like pez said, if you want to connect to the code running on your device, then you’ll want to make sure the device is running your app and you’re connecting to the right build

I am exploring, reading and trying to understand things. I saw there were three REPLs, or rather 2 + one per build if I understand correctly, and I am still not 100% clear on what the differences are. What I saw is that when I connected to the Node REPL (not the one for my build nor the browser one), I would get a message saying there is no JS runtime. I am doing a "regular" jack-in.

and no I didn't have the app running on my browser or my device at that moment, although if I am understanding correctly that is separate from the Node REPL?

Indeed, but I don’t think there is a node process running when you are building a mobile app. I could be wrong about this. Starting the app on your simulator is necessary to have your REPL connected to the app.

I see. So when the target is react-native, the node repl is not started? And if I understand correctly I can start it manually from another terminal and then connect to it from my build's REPL? I think I read this in the shadow-cljs docs

That would be true for Figwheel Main as well, so I say stick with shadow-cljs for now, it is an awesome tool.

I’ll try to see what happens if I try to connect to a plain node repl, just a minute…

thank you!

Actually I can connect to the node-repl… I guess that makes sense, it has just never struck me that it is there.

What do you see in the Calva Jack-in Terminal pane?

Mine has

shadow-cljs - server version: 2.12.5 running at 
shadow-cljs - nREPL server started on port 55194
shadow-cljs - watching build :app
[:app] Configuring build.
[:app] Compiling ...
[:app] Build completed. (146 files, 0 compiled, 0 warnings, 2,28s)

Have you started from a template or something like that?

I get this when connecting to the node REPL:

shadow-cljs - server version: 2.12.5 running at 
shadow-cljs - nREPL server started on port 65015
shadow-cljs - watching build :app
[:app] Configuring build.
[:app] Compiling ...
[:app] Build completed. (94 files, 0 compiled, 0 warnings, 4.33s)

And now if you start the app on your simulator, can you connect the REPL to it?

I can connect the node REPL to the device? or do you mean the build's REPL?

I mean the build’s REPL.

That is the important one, to get the Clojure experience in being able to modify the app you are building as it is running.

Of course, if you can’t connect Calva to the node-repl, then something is not configured as it should and that is a symptom. But the goal here should be to connect to the REPL running inside your app.

Node REPL in shadow-cljs parlance is a standalone REPL separate from your app

reading through this exchange, it’s a bit confusing. it sounds like Ray just wants to connect to the standalone Node REPL, and isn’t able to

the Node REPL shouldn’t require a build running or anything running on a device or browser

@U015GL869TQ it might be worth asking in #shadow-cljs, but I’m sure that thheller will ask you how you are starting the Node REPL. I haven’t seen how you’re attempting to start and connect to it mentioned in this thread

@U0ETXRFEW I can connect to my app while it is running. I don't think I've configured things properly to re-evaluate forms in my editor and have the result show up in the app, but when I save it reloads twice: once by shadow-cljs (super fast!) and once by expo. so I think this is ok. @U4YGF4NGM I think what you both have said tells me what I was looking for. I'm getting the sense that there is no practical reason to connect to the Node REPL in a React Native project. And if I want to do so I need to get the Node REPL to connect to an actual Node instance which I start myself. Am I getting this? Thank you both for your input by the way!

You'll want to disable Expo/react native Fast Refresh. From the dev menu of your app.

yes!

I use expo in a “bare” mode. I still use XCode, Android, etc. But I get to use their “curated” libraries which are pretty high quality. For example: https://docs.expo.io/versions/latest/sdk/in-app-purchases/ and all the others.

So far, I haven’t experienced any drawbacks with the “bare” approach. It is really like pure React Native (which I’ve also done multiple times).

I 100% agree that going with a fully managed Expo approach, at least at the moment, is questionable. A lot of limitations it seems (and they are pretty open about them).

@thheller Is that a historical accident? I mean, IntelliJ does autocompletion somehow, for all sorts of languages, without a REPL… (I am not underestimating the scope of the task, which is probably BIG). Just curious what you think.

cursive does code completion based mostly on code analysis, not by asking the runtime for data

I don't see how that's true. You can have different channels for editor tooling and evals.

I didn't mean nrepl specifically. I do not like nrepl at all, I mean a nrepl like message based protocol. not just text stream in/out, some structure

Got it.

Yes… But it also I believe it uses nREPL when you’re in the repl window. That way you can get, for example, autocompletion (on the JVM) for example with, say, vars that you declare dynamically at runtime.

But that’s not a huge part of the benefit of autocompletion. It’s like 2%.

You can certainly get more leverage out of REPL-powered auto-completion than 2%, IMO.

Oh, I guess you meant the Cursive REPL window specifically. 🙂

I can live without repl powered code completion completely. I was just using that as a basic example. there are many things a REPL may want to ask the runtime dynamically

That's true, but you can have one socket for the streaming REPL and another one for editor tooling.

point is that streaming REPLs suck for tools because of the stream nature

random prints somewhere can totally mess everything up

Yeah, you do want structured output, like in prepl.

Input can be streaming, though, and that's all that matters, really.

prepl was the fix for that yes, but it also gave up most of its power in the process

good luck starting a CLJS REPL from a CLJ prepl

so instead just use a proper message based protocol from the start and all problems are solved

What's the problem there? It works fine as far as I can tell.

it does not work, feel free to try it

I have. We might have different definitions of "works", I guess. 🙂

what did you try? I'm talking about starting a CLJS REPL from a prepl

I've only taken the first steps there, though, so there might definitely be things that don't work.

any REPL will take over the *in* and print to *out*

but in case of prepl the *out* is captured, so all "results" from the CLJS REPL will end up as regular out messages, not actual results

so prepl only really works if you never rebind in/out

(which is fine, nrepl has the same problem really)

Oh, gotcha. That doesn't really make it unusable as far as I'm concerned, though -- it just means I don't get syntax highlighting on my results. Which is a shame, of course.

but again .. start with a proper message based protocol and a REPL that is aware of that and you'll never have that problem

but if you lose features you might as well skip prepl entirely ... that is my whole point

nobody is doing this anyways so it really doesn't matter

but from a tool perspective that makes prepl unattractive. it is also the whole reason why nrepl sucks to much for CLJS. nrepl was designed for CLJ, not CLJS and it shows.

I am. 😛 But yeah, like most things, it's a tradeoff. For example, I start a prepl-like thing on top of a socket REPL, which means I can do make do with zero dependencies. Also, since it's a streaming REPL, starting sub-REPLs is straightforward.

sure .. just don't start another sub-repl from your code 😉

https://tutkain.flowthing.me/sub-repl.mov You mean like this?

no, that is cheating. you are starting a REPL that is aware of your messaging protocol. which is my entire point.

if you design REPLs from the ground up to be aware of this all the problems go away

or have your editor send a auto complete request while it is in a (break)

That works — auto-completion requests are sent over a different channel.

but how can it then auto-complete the local context?

but as you said .. you already built your own protocol on top of the socket repl

so you are using what I suggested already ...

I'm not sure what "local context" entails here. If you mean e.g. the function parameters, it currently can't -- my plan at the moment is to implement completely inside the editor.

The protocol I have is 99% prepl.

Unstructured (streaming) input, structured output.

> you are starting a REPL that is aware of your messaging protocol. which is my entire point. Not sure what you mean by this. The REPL break starts isn't aware of anything. Anyway, yes, it does print results in stdout, which is a shame, but it doesn't mean it's unusable.

never said it was unusable, just limited

You said "it does not work". 🙂

But yes, I believe it's limited.

well yeah it doesn't work as intended, showing up as output is a good fallback but thats not the intended result

Yeah, it's not optimal. I guess one possible approach to explore might be to start a ClojureScript socket REPL in a different port and connect to that, instead of having both operate over the same connection.

Anyway, if certain bits of my output not having syntax highlighting is the price I have to pay to work with zero dependencies, it's one I'll gladly pay. 🙂 It seems very unlikely that Clojure ever gets an RPC-type of thing. Of course, it's entirely possible (probably likely) there are other downsides I just haven't come across yet, of course.

Good thing we had this discussion, though -- it motivated me to come up with at least one possible solution to the syntax highlighting problem. 🙂 https://tutkain.flowthing.me/sub-repl-2.mov Obviously not ideal, but it's something. 😛 If nothing else, I can use it myself (and in possible sub-REPLs built into my editor plugin).

Hopefully this approach covers most of my own use cases, at least: https://tutkain.flowthing.me/sub-repl.png Very glad that this topic came up. :)

You can't really do that for macro-generated code, so there's at least one reason.

Mmm is that a fact? Or it’s just harder?

You can't tell what the generated code is without actually running the macro code. That's a fact.

Sure, yes. I was trying to say that it’s probably possible to include a language “runtime” in the editor/IDE and run it “behind the scenes”. You don’t need to talk to a live REPL to do it, per-se.

Impossible in the general case. Hence, impossible at all because the editor can't know if a macro is a general case or not. A macro can be an impure function.

Hmmm ok. I thought of macros as just functions that do data transformations which take some data and return valid code (data). But perhaps I’m misunderstanding. Impure function as in… writes to a file or a database at expansion time? That would be quite the macro 🙂

A macro that uses System/getenv. Or reads a config file from CWD. Or looks at the time. Or uses (random). Or a million other things.

Ah, understood. Sure. I guess I never felt/had the need to write such macros which would do those things at expansion time…

Do you have examples of such macros in the wild? (curious to look at them)

Yep, cljs.test/deftest. It defines something if and only if cljs.analyzer/*load-tests* is true during macro expansion.

And you can still mess things up when evaluation is required, in your own code:

(if (= (System/getenv "DEBUG") "true")
  (defn do-stuff [arg1 arg2] "some docstring" ...)
  (defn do-stuff [_ _] "noop" ...))