This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # babashka (83)
- # beginners (67)
- # chlorine-clover (22)
- # cider (11)
- # circleci (6)
- # clj-kondo (12)
- # cljs-dev (137)
- # cljsrn (15)
- # clojure (124)
- # clojure-europe (40)
- # clojure-italy (1)
- # clojure-nl (3)
- # clojure-norway (1)
- # clojure-serbia (3)
- # clojure-spec (19)
- # clojure-uk (14)
- # clojuredesign-podcast (5)
- # clojurescript (80)
- # conjure (49)
- # core-async (62)
- # cursive (18)
- # datascript (1)
- # datomic (64)
- # docker (28)
- # emacs (20)
- # figwheel-main (247)
- # fulcro (95)
- # graalvm (2)
- # jobs-discuss (11)
- # joker (2)
- # juxt (4)
- # lambdaisland (9)
- # leiningen (1)
- # meander (14)
- # mount (6)
- # off-topic (16)
- # pathom (46)
- # re-frame (35)
- # reagent (6)
- # reitit (5)
- # shadow-cljs (28)
- # spacemacs (6)
- # sql (18)
- # tools-deps (26)
- # vim (8)
- # xtdb (23)
- # yada (1)
Something I've been meaning to bring up. shadow-cljs has this functionality for test builds where it scans the filesystem for test namespaces, and implicitly makes them dependencies of a main namespace (a test runner ns). This makes sure not just that they are included in the build, but that they are compiled before the runner, so that when the runner compiles it can inspect the compiler env to find all tests. This makes it possible for a third party runner like Chui to exist, where people can just point at a runner ns that's provided by the library, instead of having to write their own where they manually require all their tests. I brought this up with @bhauman and he's considering if it makes sense to have something similar in Figwheel, but having it directly in the compiler so it's available regardless of the tool you're using would be even better. Thoughts?
this sounds like a divergence from Clojure? You have to require the test nses for
run-tests to work
also I don't really understand the "manually require" - the test runners that don't require analysis stuff just support a simple naming pattern matching which works just fine.
so I don't see what the gain is for end users - it's already easy right now - but maybe I missing a subtle point
the problem doesn't exist in clojure since the test-runner can just dynamically require all the tests it wants to run
in CLJS the burden is on the user to create one namespace that requires all the other test namespaces
so in shadow-cljs instead there is a generic test runner ns everyone can re-use and the requires are just provided by the build
yes I understand the dynamic require thing - but there is no such thing as a test-runner in Clojure
a test-runner implies a lot more than just dynamically requiring - which implies you have to know what look for anyway (filtering)
I think thats what the initial question is about. I think currently this isn't very easy to do.
assume that the test tool already filtered and found all the namespaces it wants to test
how does it tell the compiler to compile those before compiling the additional "test-runner" itself?
ie. if the test-runner doesn't have the requires itself parallel-build may just decide to compile it whenever without actually waiting
the compiler can compile forms, you can create test runner in memory and pass it into build no?
sorry I don't really know what the state of the official APIs for this is. just wanted to make clear why this is useful to have from the users perspective.
probably no because neither shadow-cljs nor figwheel are "in the loop" for that build path
I'm trying to imagine how this would work in practice, say someone is using
cljs.main --compile, what do I tell them?
cljs.main doesn't need to be involved, we're talking about writing a test runner easily.
yes, I can invoke the compiler myself. I get that. I don't want that. People have their own setup with their own tools, they figured out how they're dealing with dependencies and externs and whatever. I just want to add something to their build.
kaocha-cljs currently uses
repl-env which means we implicitly invoke the compiler, this leads to no end of trouble because we don't replicate people's actual setup
I'm saying it works right now, maybe not how you want it work but it is already trivial to write a test-runner
kaocha-cljs currently doesn't work for a lot of shadow users because shadow's compilation is subtly different. that's why we want to get out of the job of invoking the compiler
I don't see how ClojureScript can solve this problem - the build tools are incompatible
the thing is I can write a library and people can include it using lein, boot, deps.edn. I'd like to write a test runner that people can include with shadow, figwheel, cljs.main
to me you can't make a generic thing that works with all these build tools because they might inject something tooling specific
you could write a library to create test-runner namespaces sure (but this is like ~100 lines of code for the basics)
the other option - which is perfectly fine and it's what I currently do is not care about these tooling in my testing scenario since these inevitably ends up as CI things
right, so that's all fine, I think we're getting off track here. I don't care about these tools apart from the fact that they can compile ClojureScript. They may have their own testing features, that's not what I'm concerned with.
based on this chui offers an API for dynamically invoking tests. That API is used in browser testing UI, as well as in a component that gets tests to execute and reports on the results via a websocket
this is all just standard ClojureScript, you just add it to your build and start it with a browser or node or whatever, we don't care.
but we can only know about the tests that have been compiled by the time that macro runs
currently there are two ways this can work, either you do
or you let shadow add those requires for you
(ns foo (:require <all-the-tests>)) (capture-test-data!)
maybe there are better ways to solve this.... I don't know. As Thomas pointed out we lack the dynamic require so we can't scan the filesystem the way we do in Clojure, making it harder to provide a similar user experience
it maybe we're missing something small - you need some dep graph for
capture-test-data! to find/filter on
I did think of that but assumed I wouldn't be able to emit a require from a macro. Does that work?
like scanning for tests? analyzer apis should work here - not sure about doing test specific stuff unless Clojure has something similar
do doesn't work then a patch is welcome, I don't think this will be very hard
my gosh getting simple re-bundle on npm_deps.js file change is much harder than I imagined, but almost done
had a simple-stateful file-changed function and it was failing because well its stateful
If you don't know, there's a crc32 implementation built into the jvm. It's fairly nice to work with.
Haha. The fact you put right??? Let's me know you'd have believed me if I'd said that's how many I directly required.