I wonder how easy it is to add your own test runners for shadow-cljs, if e.g. I’d like to integrate Kaocha-CLJS, would it be possible? I’ve made an issue for Kaocha here: https://github.com/lambdaisland/kaocha-cljs/issues/2

no that would most likely not be possible

but shadow-cljs has testing stuff built-in

no idea what kaocha offers over those

I like the nice pretty-printed output of Kaocha for Clojure. The shadow test runner uses the default clojure.test reporting AFAICT?

it does but you can switch that to whatever you like

I’ve never used Kaocha-CLJS, but it seems it’s connecting to a CLJS repl via a websocket and gets the results out, then pretty-prints via Clojure.

I have not used it any kaocha neither CLJ nor CLJS so I have no idea what even the goal is

or the difference rather over normal lein test

I haven’t used lein test so I don’t know what the “normal” is either 😄

ok lets call it clojure.test

that I know

Let me rephrase my X/Y problem then — how can I get a pretty diff when my shadow-ran CLJS test fails?

if you show me what a pretty diff is I can probably tell you

dunno what that means

https://github.com/lambdaisland/deep-diff

https://github.com/lambdaisland/deep-diff/raw/master/screenshot.png

that doesn't have a cljs impl. we can't use that easily without a whole bunch of extra crap we don't really want when running tests

eg. I consider it vitally important to run tests against COMPILED builds

not some REPL eval'd code

For sure. I’m just showing that library as an example of what a “pretty diff” looks like

would this be considered "pretty"? https://github.com/pjstadig/humane-test-output

I don’t have any strong preference on what should be the ideal pretty diff, but something that helps me narrow down the difference between two possible huge maps would be nice.

I think thats the one most commonly used

Yeah that’s what I’m after. Colors are nice, but secondary. Seems like I can just require that in my namespace and it’ll do the correct thing…

don't like that it messes with the internals of cljs.pprint but I guess yes you just require it

have not used that either. just saw it before somewhere

this is the default test runner. you can write your own pretty easily

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/test/node.cljs

Doesn’t seem to work under node:

ERROR in (select-tag-simple) (TypeError:NaN:NaN)
toggling a tag on and off works
expected: (= true (gamma.state/tag-selected? selected-state tag-id1))
  actual: #object[TypeError TypeError: Cannot read property 'append' of undefined]

guess it expects a DOM? no clue

Yeah I’ll keep hunting. Point taken about running tests against compiled builds — makes total sense.

problem with koacha will be that is directly interops with the cljs analyzer and compiler

that means that it won't understand any of the shadow-cljs features such as npm integration

Seems like I should just look for a working pretty-printing library for cljs.test.

dunno how hard porting deep-diff would be. probably pretty hard as pretty much all the libs used are CLJ only.

Seems to be a known issue: https://github.com/pjstadig/humane-test-output/issues/37

And possibly trivial to fix — I’ll see if I can do it tomorrow.

seems like the only thing really required is the pretty printing

BTW: https://twitter.com/cljtogether/status/1085152627489333251

more than happy to to do the test integration stuff

already applied

I’ll keep you posted — ideally this should be something that shadow doesn’t need to change to accommodate (though perhaps in the spirit of reasonable defaults, could provide out of the box if needed).

for the browser test target I already hooked up cljs-test-display which is great

something like that just for node would be golden

I’d actually prefer to run my tests on a browser, but node was the easiest to start with (to run unit tests in a very light weight manner). How do you run CLJS tests in CI? Headless chrome?

I don't at all but others use the karma stuff

Ah, good to know. I’ll see how that looks like. Gotta run, thanks for everything (once more!)

Agree that something like cljs-test-display for node would be awesome 😄

I know hardly anything about how cljs works under the hood, so forgive me if this is a dumb question. I want to compile a cljs library into a single script file, load that file from a browser window into a script tag, and start using the library. Is that possible? Would I use shadow-cljs to do that?

@d4hines short answer, no

well, actually, I'm wrong

shadow-cljs (and the regular CLJS compiler) supports something called module splitting

so you could, as part of your build, have your library built as one module and your application built as another module

but if you want to be able to distribute that pre-built library and use it in other builds external to your application, it won't work

does that kind of make sense? 😬

What you're saying makes sense. Why it is so does not make sense. What I'm trying to do sounds really trivial (in my head, anyway), and we do it in JS all the time: write a script that attaches a useful function to some global var, run that script from the browser, then reference that global var. Why is that so hard in cljs?

@d4hines you mean use the library directly from JS?

it is not hard in CLJS. you can totally do that

the context matters though. how do you want to use it is the more important question?

Yeah, context will help. Are you guys familiar with hyperfiddle? http://www.hyperfiddle.net It's basically a fiddle environment that sits on Datomic - write a query, write a quick view in cljs, and boom - you have a scrappy little app running on datomic cloud somewhere. It already can load custom script tags, which makes it pretty easy to load vanilla js stuff, but I'd like to consume cljs libs from this environment.

I have a desire for this same kind of capability (different context, same use case). I explored it a few weeks ago and wasn't able to find a way to do it easily

the problem is that when your CLJS code is compiled, it bundles with it things like the CLJS data structures and google closure code, that is incompatible with other separate CLJS bundles

so e.g. two CLJS applications, built from separate projects, will have their own copies of the vector/map/etc. data types. which means that if you try and pass a vector from one bundle to the other, the data types won't be compatible. the thing you passed it to will treat it as a foreign JS object

Ok, so it's fundamentally a Google Closure thing, right?

Not necessarily a Clojure thing?

there's definitely some interplay there. it's the way the CLJS compilation process works

what I would love is the ability to create a bundle that left out all of that stuff, and could be placed on a page with a foreign CLJS bundle. but when I asked dnolen about it, he said it wasn't supported at all

unfortunately for me, this was a fundamental requirement for the project I'm building. so what I ended up doing is serializing/deserializing the data across those bundle boundaries 😕

... Well, our code is homoiconic. How terrible is that really?

(granted, as soon as you reference anotehr npm lib, that's broken)

well, you can't pass code between the bundles without including self-hosted CLJS

I'm just sending EDN back and forth, without behavior

Is this why self-hosted is a big deal?

@d4hines are you going to use the library from JS code or from CLJS?

CLJS.

so you are compiling CLJS? why have it pre-compiled then?

That's a good question: maybe I don't have to?

@d4hines do you have to compile your CLJS code before you put it on hyperfiddle?

No, you write it in the fiddle, like in JSFiddle or CodePen

so the fundamental problem is that CLJS builds generally include all of cljs.core and some of the google closure library

so if you already have CLJS in the page from hyperfiddle

then CLJS from your lib

then CLJS from your extra code

means 3 separate cljs.core instances on the page

which is bad

you could strip out all of cljs.core and assume it provided

but that only work when using no optimizations

meaning huge builds

clojurescript is different than JS because it has macros

so even if you strip out cljs.core you still need access to the macros somehow when compiling your lib code

so you could potentially end up compiling against a different CLJS version

in short it is not advised at all to do this in CLJS

you can make something work but its gonna suck big time

if you just want a standalone library that provides a JS API thats not problem

it sounds like hyperfiddle already has self-hosting. so if your library is self-host compatible, you might be able to do what you were saying where you load the file and eval it

Self-hosting in hyperfiddle means running the backend services yourself. You're talking about the host language right?

I mean "self-hosted ClojureScript"

i.e. you can (eval '(println "foo")) in ClojureScript

in "normal" CLJS projects, this isn't supported (and usually isn't needed 😉 )

there are ways to setup your project to use it though. it sounds like hyperfiddle already does, since it's executing your CLJS code in the browser

Yes, that's all true.

That will break down as soon as an external lib (like an npm lib) is referenced though, right?

right, if you need some external dependency, you'll need to load that too

and reference that in a way that it can be accessed on the page

honestly I would ask @dustingetz how he would try and do this 😛 he's building hyperfiddle

I was just chatting with him.His solution (and this sounds much more practical), is to just host hyperfiddle yourself, and include whatever deps you need at build time. I just wondered why we can't do what JS can do, which ya'll answered very well (thanks!)

we can do everything JS does. its not different really, JS has pretty much the same restrictions

just remember that you are not just using YOUR library. you are also using cljs.core and some of the closure library

to compare with that a JS library assume that your JS lib wants to use immutable-js + lodash or so

so you are paying the extra overhead for loading those too

if you accept that then CLJS is no different

you just can't do jQuery style libs where everything assumes that there is a global jQuery loaded somewhere

stitching things together via some global variables won't work

Not even with eval?

Like lilactown was saying?

eval fundamentally needs access to the source which isn't what you wanted AFAICT

and no not even with eval

so, for my use case. I am building a dev tool that I want to allow people to extend with their own 3rd party plugins

would I be able to instruct people building those plugins how to build their CLJS code in a way that could interface with my main dev tool application?

cause right now, the solution I have is to communicate via stringified-EDN or transit and hand them a DOM node to render their plugin to 😕

@lilactown not sure I understand but no you cannot pass CLJS collection instances between different cljs.core versions

they will not be compatible

right. I've gotten that far

normal JS interops works as normal

would I be able to instruct people building those plugins how to build their CLJS code in a way that could use my application's version of cljs.core?

and React

if you are fine using no optimizations at all?

but generally no that won't work

it is a developer tool 😜

you want to build something REBL like right?

OK, I'll have to think on that. there will be times that this lives on the same page as a user's application at development time, so I also need to make sure I don't clobber their application's cljs.core etc.

yeah

thats gonna be much much much harder in CLJS than CLJ

problem is ensuring the library code uses the same version of everything your code uses

but unoptimized code can be combined at will

just need to "trick" the loader a little

I really appreciate the explanations guys.

with shadow-cljs, would :output-wrapper be able to ensure I don't clobber a user's application?

not sure what you mean by that

I thought the goal is to incorporate user code into yours?

but honestly don't waste your time trying to do this

protocols and all that stuff won't work properly

its just gonna be annoying as hell to work around all the limitations

there's 3 types of things that might be living on the page: - user's application - REBL application - 3rd party REBL viewers

ah ok. yeah don't do that

load REBL code in an iframe or so

do not load it in the users application

but yes :output-wrapper would isolate everything

well. right now, I'm compiling the REBL application and keeping it to one module. so it should be isolated

the user's application communicates to it via EDN + some JS interop

what I'm trying to figure out now is how the 3rd party REBL viewers will hook into the REBL application

probably want to use a plain JS API

no CLJS collections

not sure how that would work in a REBL style application given its protocol heavy nature

atm, the user installs a library in their application code that handles serializing and sending data to the REBL application, and listening for events and calling nav / datafy

but thats gonna be pretty inefficient

yep 🙃

in my testing I haven't noticed any real perf problems. but I've yet to use it in really complex applications

but the upside, is that it works in Node.js too

and eventually JVM Clojure

it just connects over a websocket

still no clue how any of that would actually work though

nav + datafy are protocols and sometimes on metadata

you can't serialize objects that have those in metadata

well you can but you are gonna lose the meta impls

the way it works right now is that when you want to send something to the REBL app, you tap> it

gotta go, bbl

the library the user installed, adds a tap listener that adds the data as an entry to a global atom and sends it over the wire for viewing with an ID that it can use to reference the entry in the atom

anytime the REBL app needs to call nav or datafy, it sends an event back to the user's application to call nav or datafy on the entry in the atom and then send the result back to the REBL app