This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-22
Channels
- # announcements (39)
- # architecture (9)
- # aws (2)
- # babashka (17)
- # beginners (73)
- # calva (6)
- # cider (27)
- # clj-kondo (140)
- # cljdoc (67)
- # cljsrn (1)
- # clojure (99)
- # clojure-dev (4)
- # clojure-europe (35)
- # clojure-nl (7)
- # clojure-spec (19)
- # clojure-uk (2)
- # clojurescript (40)
- # community-development (3)
- # cursive (10)
- # datalevin (2)
- # datavis (2)
- # datomic (27)
- # deps-new (5)
- # events (2)
- # fulcro (38)
- # integrant (6)
- # jobs (3)
- # keyboards (1)
- # leiningen (13)
- # lsp (3)
- # malli (10)
- # meander (5)
- # membrane (1)
- # membrane-term (9)
- # missionary (3)
- # off-topic (29)
- # polylith (3)
- # reagent (3)
- # reitit (5)
- # remote-jobs (2)
- # reveal (7)
- # shadow-cljs (20)
- # tools-build (4)
- # tools-deps (8)
- # vim (10)
- # xtdb (3)
I’m trying to create a single project with a clj backend and a cljs frontend… hence I have both a deps.edn and a shadow-cljs.edn (don’t know if that’s correct)… when I cider-jack-in-clj everything works on the clj side… when I cider-jack-in-cljs everything works on the cljs side… but when I cider-jack-in-clj&cljs the clj side has numerous compilation problems on the requires of the first namespace I evaluate… thoughts?
update: I also don’t get a cljs repl apparently when using cider-jack-in-clj&cljs.
jack-in-clj&cljs is when you can create a clojure and clojurescript repl in the same process. since you are using shadow you cannot do this. because shadow is a separate process from your clojure backend process
for instance, if you were using figwheel-main, you would start up two repls, and in one you would just require figwheel.main.api
or whatever the namespace is that cranks up the cljs stuff. and then you have "upgraded" one of the clj repls into a cljs repl. but for your setup you start two different programs so this technique won't work for you
that function has probably caused more confusion than benefit and perhaps removed. just start your two repls independently because they are independent
at the top of the repls should be a startup command and a command that turns your cljs repl into a cljs repl. I put those in the startup text to take some of the mystery out of the tooling. I think if you see those two you'll get some more insight why this doesn't work
ah cool… lemme look at that now.
Ah, yep… that’s really helpful, actually.
@macrobartfast That's the greatest, yet most underappreciated command in all of CIDER!

i wish M-x cider-connect had an own history ring for the port number...
@leah I guess this should be easy to implement. I typically connect to a locally running server instance, that's why I never thought much about storing the ports (in my case they are typically random). I guess this also makes a lot of sense for remote hosts. Feel free to file a ticket on the subject.
Yeah, I guess I could let it autoconnect too. Thanks!
Might be useful in your use case (assuming you want to connect to the same port on the same host).
Do people here have an opinion on the role of Emacs in the upcoming "wave of devcontainers" paired with "in-browser software development" ? In this, every open-source project will configure "centrally" one development setup (including tools + IDE + IDE configuration). This does match badly IMHO with Emacs (technically and philosophically), unless we address this.
I see value in using containers for local development, but I don't see much value in forcing people to use specific development tools.
I hope I never have to worry about that issue. But, there has been some work done getting emacs working on gitpods: https://github.com/emacs-lsp/lsp-gitpod
One way to address this in Emacs would be to have a way to support "devcontainers". There is not accepted standard yet, but VSCode specifies a "json file", which allows (VSCode for teh moment) to build automatically an Docker image from a Dockerfile and it runs on startup commands on it, so you get a docker container running, with all tools installed inside. Big parts of that json file are independent of VSCode or any IDE, so could be in theory used cross IDE.
Docker is not a big subject for Clojure development thanks to the JVM.
And companies might then follow.
Hmm, maybe I should have asked https://clojurians.slack.com/archives/C053AK3F9/p1637621834098200 here? 🙂