Fork me on GitHub
#shadow-cljs
<
2018-03-16
>
eoliphant00:03:05

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.

p-himik04:03:33

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

p-himik04:03:56

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?

p-himik05:03:18

Ah, found https://github.com/thheller/shadow-cljs/issues/167 Hard to find when all the text is in images. 🙂

thheller09:03:30

@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?

p-himik09:03:24

@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.

thheller09:03:48

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

thheller09:03:43

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

thheller09:03:58

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

darwin09:03:45

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

thheller10:03:24

@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

darwin10:03:10

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).

thheller10:03:15

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

thheller10:03:47

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

darwin10:03:30

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

thheller10:03:59

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

darwin10:03:02

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

thheller10:03:09

it completely reimplements all REPL related things

darwin10:03:18

here I collect all compiler descriptors available to Dirac: https://github.com/binaryage/dirac/blob/master/src/nrepl/dirac/nrepl/compilers.clj#L89 you can see that I collect dirac’s own (in nREPL) and add figwheels if avail

darwin10:03:28

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

thheller10:03:47

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

darwin10:03:26

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

thheller16:03:45

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

mhuebert16:03:35

Great, will try it out

fbielejec18:03:42

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"}

thheller19:03:33

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

thheller19:03:37

you mean the compiled version?

thheller19:03:31

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

justinlee19:03:08

@thheller I don’t know if you saw in #clojurescript but I pointed someone who wants to embed cljs in an existing project to https://shadow-cljs.github.io/docs/UsersGuide.html#target-npm-module but i’m not sure that’s the best method

thheller19:03:10

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

fbielejec20:03:47

@thheller from another cljs project to start with.

thheller20:03:32

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

thheller20:03:19

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