Fork me on GitHub

just wanted to drop a note @thheller shadow is amazing. You tried to help me get it goign with a luminus generated project a few weeks ago. But I kind of gave up as i was under a crunch, but just got back into it and abandoned trying to get it working with lein and just did it standalone. literally took like 15 minutes. clojure(script) is awesome, but dealing with the rest of the JS world is a bit of an s-show IMO, this really makes it just work.


@darwin Thanks! No warning now. Although the option should be :skip-paranoid-middleware-setup-check.


Just running (require '[cljs.repl]) leads to the same error. But running (require '[cljs.core]) is just fine. Removing all shadow-cljs lines from :init and :nrepl-middleware solves the issue. Do you have any idea on why it might be happening?


Ah, found Hard to find when all the text is in images. 🙂


@p-himik I'm not sure what you are trying to do. why require cljs.repl? why require cljs.core? does requiring your code work?


@thheller I'm just testing - that's what Dirac requires when it starts, as far as I can tell. Yeah, everything else appears to be working.


looking over the dirac architecture I don't think dirac is going to work


> With specific setup, Dirac is able to use Figwheel's compilers for REPL evaluations. Dirac nREPL middleware looks for Figwheel sidecar presence


it already does special detection for figwheel. so it would have to do that for shadow-cljs as well


exactly, Dirac needs to talk to some CLJS REPL environment on server-side, normally it does that via its own fork of piggieback running on top of nREPL, but it can optionally switch to Figwheel’s REPL running on top of nREPL, it would have to do the same for shadow-cljs-managed CLJS REPL as well


@darwin but why fork piggieback? why not use the binding it sets? I already emulate piggiback so that the expected cemerick.piggieback/*cljs-compiler-env* binding is set in the session


I don’t remember the exact reasons, but it was easier for me to simply fork it and do my own thing. I ended up rewriting it. Unfortunately piggieback was really hard to understand (for me).


I still don't understand piggieback. I work around it to.


but you said you need to the compiler env which is available via a binding so you don't need to mess with the rest


I wrote this code few years back, I’m sorry I don’t remember


well problem either way is going to be that shadow-cljs doesn't use the default cljs repl env stuff


but if I recall correctly, I need compiler env in the same JVM as dirac nrepl middleware is running, if I can get that I can compile stuff


it completely reimplements all REPL related things


here I collect all compiler descriptors available to Dirac: you can see that I collect dirac’s own (in nREPL) and add figwheels if avail


there I could add yours, if I had access to them


I'll take a look at it later. no clue whats going on there and not enough time to get started now.


sure, no problem, just wanted to let you know that I’m open to add support for shadow-cljs, if possible


@mhuebert I just pushed [email protected] which should fix your issue from yesterday. the require('mongoose') thing.


Great, will try it out


Say I have two namespaces, lets call them * ns-a with a hello-a function signature * ns-b with a hello-b function signature Can I have a build, that releases this as a library usable both from the browser and on the server (nodejs)? Also another question - say that one of these functions (`hello-a` for example) needs a slighty different implementation (for example a different socket client for a browser and nodejs), but after production release I still want the user to be able to just do:

(:require my-lib.ns-a :refer [hello-a])
and get the right implementation regardless of where she is running the code. Ideally without increasing the bundle size (so either without programmatically detecting the process, or by dead code elimination)? In the end:
(defn hello-a []
 (if process.browser
   "Hello from browser"
   "Hello from node"))
should become in the browser
function hello-a () {return "Hello from browser"}
and when required in nodejs env it becomes:
function hello-a () {return "Hello from node"}


@fbielejec not sure what you mean by "releases this as a library usable both from the browser and on the server"


you mean the compiled version?


for the other thing you can use a goog-define which works with DCE and should do what you want


@thheller I don’t know if you saw in #clojurescript but I pointed someone who wants to embed cljs in an existing project to but i’m not sure that’s the best method


I saw yes. depends on the project but it is a good option yes.


@thheller from another cljs project to start with.


for CLJS I would suggest 2 different namespaces otherwise you might get into all sorts of trouble if your users forget to set the closure-defines properly or so


you want to rely on DCE as little as possible and use other more reliable options