Clojurians Log v2

Hey @plexus, did you create another a cljs test runner that is not Kaocha? I have vague recollection of this but now can't find anything

@miikka personally I’ve been using cljs-test-runner by Olical

Which mimics the Cognitect labs test runner

@miikka you're thinking of Chui

@borkdude those aren't test runners, they are test runner proof of concepts 😛

works for me

Yes, Chui!

which is really just a piece of the puzzle for kaocha-cljs2, but it can also be used standalone, or be a library for other cljs test tooling

I've put a lot more work into kaocha-cljs2 the past few weeks as well, including figuring out how it'll work outside of shadow-cljs.

but it relies on https://clojure.atlassian.net/browse/CLJS-3276 which might take some time to get merged

@plexus Cool, so CLJS-3276 will allow more dynamic forms of require at compile time (e.g. using env vars etc.)?

you can use env vars already

I thought CLJS only processes top level require forms outside ns. So how does one do that?

ah yeah no you're right, if you want to generate a require statement with a macro (which may check env vars) then you need this

yep, so that's neat to have

I'm doing something very similar to CLJS right now in babashka for creating uberscripts. But CLJS-3276 might be cool to support there as well

currently ClojureScript starts from the top of the files, if it finds an ns form it uses that, if it finds require statements it reads them until it finds some non require statement and then merges them as if it's a single ns form

(technically I think you could have requires followed by an ns, but not the other way around)

Ah, I thought it supported additional requires after the ns form

so this patch does two things, it continues reading after ns to see if it finds require statements there, or if it finds another form it check if its a macro (based on the previous ns form), if so it loads the macro, analyzes it, and if it turns into a require it processes it

making sure the macro is able to be expanded is the most tricky part because normally loading macros happens in a later pass... I managed to work around it but waiting for David to tell me if this solution is acceptable or if he has other ideas for how to tackle it

:thumbsup:

the reason we need this is that Chui also uses a macro to inspect the compiler state and find test vars. For that to work we have to be sure that this test-finding-macro only gets compiled after all the tests have been compiled, so conceptually you need this

(ns foo
  (:require alll...your...tests)
  (:require-macros [find-tests!])))

(find-tests!)

but, we don't want to tell people to manually require their tests. That just leads to someone forgetting a test and it never being run. Shadow-cljs has provisions for this, if you use :browser-test or :node-test you can give it a test ns, and it will inject the necessary requires

i'm glad to see this problem tackled outside of shadow-cljs

I've seen other solutions to create ns forms dynamically at read or compile time, but I think this one is more flexible and applicable to more than just kaocha.

(i mean, the shadow-cljs solution is good too, but not going to migrate all the non-shadow-cljs projects to shadow-cljs when i need to touch them :P)

I tried to propose adding similar functionality to the cljs compiler, but that wasn't warmly received. Instead David said "just use a macro", and I thought, "great", except that it turns out it doesn't work 🙂

heh, yeah

so... (inc yak-stack)

I don't think assuming shadow-cljs everywhere is great. It should be a choice

I know I know... but one of the reasons for kaocha-cljs2 is that we need some way to support people using shadow. Turns out that that is actually pretty easy because shadow has good testing provisions, but now it's a lot more work to support the rest again.

but yeah David agrees that this should work so I'm sure at some point it will work, and then we can support vanilla cljs as well as figwheel, lein-cljsbuild, etc.

the core of the issue of course is that shadow is really a different compiler from all the rest, so if people use shadow then all builds have to be done by shadow. If people use figwheel then we could still do a build with cljs.main as long as we have the same compiler opts

This is kiiiind of the reason I'm still using cljs-test-runner, although you call it a POC, it works great for my purposes ;)

But great to hear about the progress

I guess cljs-test-runner is kind of minimum viable test runner

To be honest, I don't need much

I mean you could use kaocha-cljs, should work just as well. cljs-test-runner is really just a wrapper around doo, which does the compile-everything-to-a-blob thing, which I dislike because it lacks observability

Same with CIDER: it has tons of features, but I probably only use 5% of them

@plexus I've tried it but last time I tried it it didn't work with advanced compilation tests

true, it relies on a repl-env which implies :optimizations :none, but that's one of the use cases that kaocha-cljs2 will support

I've now worked a couple of months in this team where we maintain something like 20 services and the clojure/cljs ones just use lein test and Doo, and it works just fine... but if I ever need watching or Doo breaks, I'll introduce Kaocha

but well, it's always the Scala or the JS services that need the attention 😎

@tavistock you can try bin/proj install now if you want to install a local copy of kaocha-junit-xml

➜ bin/proj
Usage: bin/proj [COMMAND] [COMMAND_ARGS...]

  release                            Release a new version to clojars
  pom                                Generate pom files
  install                            Build and install jar(s) locally
  gh_actions_changelog_output        Print the last stanza of the changelog in a format that GH actions understands
  help                               Show this help information
  inspect                            Show expanded opts and exit
  gen-readme                         Generate README based on a template and fill in project variables
  update-readme                      Update sections in README.md

code is here http://github.com/lambdaisland/open-source/ if you're managing multiple open source projects and you want some unified setup, or if you have projects that consist of multiple sub-projects in one repo then this might be quite useful. I was surprised at the lack of good solutions for building/releasing libraries (and not just applications/uberjars) with deps.edn

A new kaocha-cloverage is out, it just bumps cloverage to 1.2.0, which again seems to contain a bunch of fixes and improvements. Thanks @cksharma122 for doing the upgrade!

👋:skin-tone-2: hi @bozhidar and @wxitb2017

Hi @plexus 👋, i have been trying chui / kaocha-cljs2 , and it looks really promising! Thanks for the great work.

One thing that i miss most in shadow-cljs is the ability to only run a subset of tests, seems now I can do it with kaocha-cljs2!

hey that's awesome! kaocha-cljs2 is still pretty fresh but we're using it at Nextjournal and I'm actively working on it. If you find anything that bothers you let me know. Some user reports would be really helpful at this point.

I'll update the docs soon to have some better instructions on how to set things up with or without shadow

Is there a way to specify plugin for specific profile like only for :unit ?

No, plugins operate on a test run.

Hey @plexus, I am trying to migrate to kaocha-cljs2 and don’t quite see how to plug it together with :node-test and shadow. I see there and node runner and a shadow-cljs runner but it looks like neither of those cover my specific use case

Okay looks like I am piecing it together a bit, I want to run the :browser-test config

Okay more piecing together. I can run some tests but those that depend on node.js libs don’t work because we are actually running in the browser

so I need to feed a node.js processes output to chui which should be running in its own process to render out the ui?

and this is connected via funnel?

something also these lines?