This isn't entirely trivial for us @borkdude but I agree it would be nice to have. Would be glad to assist someone in shepherding a pull request. I made an issue of your comments here and provided some more background on the issue. https://github.com/lambdaisland/kaocha/issues/145

https://github.com/lambdaisland/funnel

Funnel is a new project, and a building block for the to-be kaocha-cljs2. The idea is that people run funnel in a terminal or in the background somewhere. It can pretty much keep running forever. The JavaScript runtimes that will execute the actual tests will connect to funnel. Kaocha-cljs2 will also connect to funnel. So it becomes a central hub for communication. Why? Currently we spawn a new runtime on every test run (browser tab, node process), and wait until it connects back to us. That's all we can do, there is no way to connect to the runtime. We have to passively sit and wait until it connects back. That means that currently there is no good way to reuse for instance a browser tab, because there is no way to tell if a browser tab exists that may or may not try to retry its connection.

But now those tabs conencts to funnel, and funnel holds on to those connections, so when we start a new test run we can query funnel and find out which runtimes there are, and we can immediately communicate with them.

I've tried to make funnel very generic, it contains some basic rules for how to decide which message goes where, but for the rest it's very "simple". How you want to communicate on top of that is up to you. Some other use cases this could be great for are ClojureScript REPLs, and remote object browsers a la REBL.

Eventually we may hide this to some extent for the user by starting funnel in the background the first time we run, and just leaving it running, but for starters I think we'll have people run it explicitly. By increasing the verbosity you get a nice log of the communication, open connections, etc, and so it's a good inspection point for troubleshooting. The repl-envs that kaocha-cljs currently uses hide a lot of the communication (e.g. stdin/stderr of the node process are swallowed, there is no way to see them), and this has been a big source of frustration because it makes all issues look the same ("Client failed connecting back", i.e. a timeout), with no useful or actionable information.