Fork me on GitHub

@mauricio.szabo in general, what do you think it would take to get Chlorine working with figwheel-main? If I have time, and you’re interested, I wouldn’t mind looking into this…if for nothing else than curiosity.


Great, thanks! So, the way that it currently work is the following: everything starts on this file/line:


If you follow the paths, you'll get here: This is probably the first line that needs to be changed - something like "use the current :clj/aux REPL to discover if we're running shadow-cljs or Figwheel-main"


Currently, there's a special "evaluator" for Shadow-CLJS that uses its internal APIs to evaluate code. This will probably be the default for Shadow in the future. But the "old API" still exists: it basically needs a host / port, and a command. It'll connect to a Clojure REPL, then run a command to transform that REPL in ClojureScript:


It is also a good idea to save information on how to get the current ClojureScript env from Clojure code, then save it on the "global state":


(sorry if its a little overwhelming 😄)


This is a good start! Thanks 🙂 I will follow up with questions I may have.


Great! I think for figwheel you'll have to add piggieback even for Socket REPL to be able to transform the REPL into a CLJS one


At least, when I started to check figwheel-main I had this problem. Don't know if it still exists today 🙂


@mauricio.szabo Where do I have to change to automatic start deps.edn and connect to it?


can be direct to


You mean like a jack-in command, or something?


yes, somethink like that


because I have to write the command into source code to remember 🙂


Add it as an :alias in your ~/.clojure/deps.edn file?


BTW, there's a FAQ where I explain some of design decisions on Chlorine, and there's a section for Jack-in: The problem with these solutions is that you're inside an editor (that's not known to be fast nor memory-friendly), and then you start a Java process (that's also hard on memory)...


Also... there's lots of coordination for jack-in to work: it's already kinda hard to coordinate between states on the editor (like, when someone connects, disconnects, starts a CLJS REPL, watch configs, the inline results). To add an external process into the mix can become really complicated...


There's also the customizability aspect: as soon as you offer jack in, folks will want to be able to customize all sorts of aspects of it and that gets really nasty.


Because of the way we run REPLs at work, I don't think any "built-in" jack-in functionality would ever work for us... I mean, it would basically need to allow us to enter an arbitrary command to start the appropriate REPL... so why not just type that in at the command-line anyway?


Also, I tend to start a REPL (from the command line) and run it for days, sometimes even weeks -- so I'd only need "jack in" once a week or less. Seems like a waste of time to divert effort to such a feature.


(I've never really understood why CIDER expended so much effort on that... except for it already being a complete "kitchen sink" plugin anyway)


I imagine because it's hard to coordinate all dependencies that it needs to run. This "feature discovery" that I do on Chlorine is yet another state control 😄


Ah, and I have no idea what "kitchen sink" means in this context 😄


Slang for "includes everything"


Ah, there's also the problem with env vars! Most editors don't set the environment variables correctly when running external processes. This is not a problem, except when you add private repositories on the mix... and now the REPL doesn't start with bizarre errors