This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-16
Channels
- # atlanta-clojurians (8)
- # beginners (103)
- # boot (22)
- # boot-dev (1)
- # cider (36)
- # cljs-dev (55)
- # cljsrn (3)
- # clojars (25)
- # clojure (104)
- # clojure-brasil (1)
- # clojure-dusseldorf (2)
- # clojure-italy (8)
- # clojure-norway (9)
- # clojure-russia (15)
- # clojure-spec (6)
- # clojure-uk (26)
- # clojurescript (246)
- # cursive (26)
- # data-science (1)
- # datomic (22)
- # dirac (11)
- # editors (1)
- # emacs (8)
- # fulcro (50)
- # graphql (11)
- # hoplon (1)
- # jobs-discuss (27)
- # leiningen (44)
- # luminus (33)
- # lumo (2)
- # mount (1)
- # off-topic (8)
- # onyx (5)
- # parinfer (4)
- # reagent (94)
- # ring-swagger (14)
- # shadow-cljs (37)
- # spacemacs (10)
- # specter (3)
- # tools-deps (4)
- # unrepl (14)
- # yada (5)
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 https://github.com/thheller/shadow-cljs/issues/167 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.
> 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).
you would not recognize this code 😉 https://github.com/binaryage/dirac/blob/master/src/nrepl/dirac/nrepl/piggieback.clj
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
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
here you can see, how hard was figwheel integration: https://github.com/binaryage/dirac/blob/master/src/nrepl/dirac/nrepl/figwheel.clj
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
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.
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"
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 https://shadow-cljs.github.io/docs/UsersGuide.html#target-npm-module but i’m not sure that’s the best method