@danielcompton this is mostly intended to give better error messages e.g. when you reconfigure kaocha. See also https://github.com/lambdaisland/kaocha/issues/104

The more we can do with plug-ins the better, it makes kaocha itself less bloated, and encourages a marketplace of ideas, where people can always swap out a plugin for their own if they don't like it

Given the above I think limiting the call to orchestra to only instrument kaocha's own namespaces would be good. It's important that this runs early so it catches configuration errors. On top of that we can provide a plugin that instruments after load.

Cool, that makes sense!

another plugin example https://github.com/lambdaisland/kaocha/issues/110

releasing a new kaocha-cljs as we speak, please do try it out and report back. If you had issues in the past it would be great if you could try it, it should be more stable and reliable than before

[lambdaisland/kaocha-cljs "0.0-51"]
lambdaisland/kaocha-cljs {:mvn/version "0.0-51"}

just a heads up, matcher-combinators is not compatible with kaocha-cljs: https://github.com/nubank/matcher-combinators/issues/83 although that might be fixed soon-ish

In other news I'm considering adopting the C4 model for my projects, starting with kaocha-cljs

C4 = Collective Code Construction Contract

- Definition: https://rfc.zeromq.org/spec:44/C4/ - Elaboration: https://hintjens.gitbooks.io/social-architecture/content/chapter4.html

What this mainly means in practice is that pull requests will be accepted and merged quickly by default. Code review if necessary happens out of bound by submitting another pull request.

What this also means is that I am as of immediately looking for a second maintainer for kaocha-cljs, this can be a largely symbolic function if you want, just a second person to hit "merge" from time to time, so I don't have to merge my own patches, and can feel a little less alone 😉