Since doo-run-all can take a regex to limit the namespaces to run, in some cases it may be preferable to defer filtering namespaces to runtime - the holy grail of truth.
Since we need to enumerate the namespaces anyway currently to make sure they're loaded, in most cases this is not really worth it, but perhaps it makes the most sense in the case of using explicit .cljs.edn files (where the requires are known).
Currently this plugin plays-safe and subsets namespaces to test to those directly required by the edn file, but this would be an easy way out. Other possible cases could include files defining additional namespaces (through extra ns forms or magic macros?). Not sure if these are real cases.
Using an approach like this we could even collapse generic includes and excludes into a single (though eldritch) regex.
Just capturing this idea, but it may be nonsense.
Once doo supports filtering actual test cases, this exact problem comes back with a twist though, so no thought on it is wasted.
Since
doo-run-allcan take a regex to limit the namespaces to run, in some cases it may be preferable to defer filtering namespaces to runtime - the holy grail of truth.Since we need to enumerate the namespaces anyway currently to make sure they're loaded, in most cases this is not really worth it, but perhaps it makes the most sense in the case of using explicit
.cljs.ednfiles (where the requires are known).Currently this plugin plays-safe and subsets namespaces to test to those directly required by the edn file, but this would be an easy way out. Other possible cases could include files defining additional namespaces (through extra ns forms or magic macros?). Not sure if these are real cases.
Using an approach like this we could even collapse generic includes and excludes into a single (though eldritch) regex.
Just capturing this idea, but it may be nonsense.
Once
doosupports filtering actual test cases, this exact problem comes back with a twist though, so no thought on it is wasted.