Fork me on GitHub
#shadow-cljs
<
2017-12-29
>
dominicm08:12:31

Okay, passed the default-config, and success!

dominicm08:12:35

I see a build happen.

dominicm08:12:03

Can't seem to get autoload working, hosted from http://localhost:3000. I see my browser connect to http://localhost:9630/ws/worker/app/f02d4ea2-71cd-418f-8f6a-888ea31e9846/c809ecc7-6d24-48d2-848e-89636113d1d0/browser (and the 9630 server is running!). In my console log I see:

DEVTOOLS: connected!
browser.cljs:25:10
DEVTOOLS: disconnected!
browser.cljs:25:10
Immediately after one another.

dominicm08:12:20

The rebuild is happening, I can see it at my REPL.

dominicm08:12:19

I have :devtools {:autoload true} in my build config fwiw

dominicm09:12:42

Looks like my lack of logger is causing any log messages to end up in the void, so I'll rectify that first

dominicm09:12:04

user=> [XNIO-1 I/O-3] WARN - stale websocket client, no worker for build :app there we are. Something to work with!

dominicm09:12:12

Looks like namespaced build ids aren't supported/working.

dominicm10:12:20

I'm struggling with using reagent/rum, I think due to their dependency on cljsjs.react. I'm getting The required JS dependency "react" is not available, it was required by "cljsjs/react.cljs". Is there a config or something I need to use?

thheller11:12:37

@dominicm shadow-cljs uses npm not cljsjs. so you need to npm install react react-dom create-react-class

thheller11:12:34

oh. I did not expect namespaced keywords. they currently break yes.

dominicm11:12:55

@thheller using npm is mandatory, not optional?

thheller11:12:35

I thought about supporting it optionally but no one asked for that yet

thheller11:12:54

the systems don’t mix well so you’d either need to use cljsjs for everything or nothing

thheller11:12:13

npm for everything works way better and doesn’t rely on re-packaged cljsjs

dominicm11:12:19

sure. Catches for me are: * we already have code using cljsjs * how do you work with supporting libraries that only work with cljsjs?

thheller11:12:20

has a section about migrating from cljsjs

thheller11:12:42

since probably all the things in cljsjs come from npm that should always work

dominicm11:12:31

I also have a difficulty for my particular setup now, which is that I need to figure out how to "merge" npm dependencies, I can't rely on the classpath anymore.

thheller11:12:18

still not sure how your setup looks so can’t comment much

thheller11:12:33

but yeah merging npm is going to be a problem

thheller11:12:49

I would probably recommend creating a /cljs directory in your monorepo with /cljs/package.json for npm and /cljs/shadow-cljs.edn

thheller11:12:55

put all your builds configs there

thheller11:12:13

include all source paths and deps

thheller11:12:34

and then use the :output-dir to ../shop-clientA/public/js or whatever

thheller11:12:15

one place to manage CLJS builds, one JVM instance for all of them

thheller11:12:00

I really would not recommend running shadow-cljs in your JVM alongside the JVM stuff

thheller11:12:17

that is just going to be annoying and nullifies all optimizations I’m doing for shadow-cljs

thheller11:12:17

running it with other JVM deps is just going to run into all sorts of conflicts

dominicm11:12:47

Oh, there's something additional to cljs/clj dependencies conflicting? What is the problem?

thheller11:12:28

no idea, you already ran into one issue with undertow

thheller11:12:22

shadow-cljs has a bunch of dependencies and I don’t guarantee anything if you override those

thheller11:12:52

eg. in your TDEPS issue you were using undertow 2.0.0.alpha which I don’t use for shadow-cljs

thheller11:12:03

dunno if that breaks anything since I never tested 2.0

thheller11:12:16

it might work but it might not

thheller11:12:05

I will also soon add the ability to add dependencies without restarting

thheller11:12:17

that will not work when running the embedded version

thheller11:12:50

well it might but I can’t promise that it won’t break anything on the CLJ side

thheller11:12:36

and you really do not gain anything by running shadow-cljs (or any other CLJS tool) alongside your CLJ stuff

thheller11:12:03

you are just asking for trouble IMHO

thheller11:12:13

I do want to support using shadow-cljs as a library but it is making things a lot harder and you don’t benefit by most of the optimizations I’m doing regarding performance and startup time

thheller11:12:01

I personally switched to running one lein repl for everything CLJ and one shadow-cljs instance for everything CLJS

thheller11:12:21

removed sooooo much pain I had previously

thheller11:12:37

gotta go, bbl

dominicm11:12:49

The big win that I can see for having it all in one JVM is that most tooling (CIDER, etc.) works better if you do that. There's also less "fiddling", we use datomic, so we literally can do boot launch and everything we need is started. It's a nice experience. We've not had any issues with mixing cljs & clj dependencies in a project in the past. Although, one time I did manage to get cljs running in it's own boot pod, with it's own dependencies, it was a nice hack. The thingis, it didn't solve any problems, so we never used it.

dominicm11:12:16

I think parts of shadow could be moved inside clj-embed or some other isolated runtime, including undertow.

dominicm14:12:22

I was just thinking about how this could be resolved, and it occurs to me that I'm surprised that cljs doesn't allow libraries to have their own npm dependencies. What happens in the case that:

cljsA -> npm-deps [jslib 1.0]
cljsB -> npm-deps [jslib 2.0]
with normal clojurescript? Does cljsA get jslib1.0 and cljsB get jslib 2.0? That would make sense to me in a "node.js world", so I will be surprised if nobody has at least considered this before.

tianshu16:12:21

I think the om.dom in om is broken with shadow-cljs. but if render with other library(sablono), that works.

thheller20:12:31

@dominicm I don't allow that since I don't want 2 versions of the same lib in the release bundle since size matters in the browser.

thheller20:12:58

and it is not allowed for the JVM anyways

thheller20:12:21

@doglooksgood what makes you say that? om.dom should work just fine.