This has been my hobby project for the last week. Still pretty half baked.
The tl;dr is that this PR rewrites teenytest to implement most of its user-facing logic into plugins (docs). The internal plugins are all defined here and loaded by the runner here.
This is a pretty drastic detangling of all the runner-time logic teenytest contained before, and should allow us to do things like have user-defined plugins which transform test functions like #14 with promises or a first-class reporter plugin (in lieu or in addition to the TAP13 one) as #15 wants.
[x] formalize, test, and fix with greater certainty which hooks should run in which situations & states (see the reliable-hooks tests
[x] define and test/implement what to do when a single scope of the test has multiple errors (basically: batch and report them all)
[x] test to specify what to do when a suite-scoped plugin passes an error to its callback, as that's not actually possible with OOTB teenytest & its built-in plugins
[x] make the meta-test helpers a little more rigorous. they still swallow too many errors though (requiring debugging + catch all exceptions)
[x] allow CLI users to register plugins, as currently any registered in JS would require you run teenytest using the JS API, which nobody does
maybe a $ teenytest --config some/requireable/path which would in turn export a function registering what it needs with teenytest, and invoked by teenytest's runner
maybe a package.teenytest.plugins config path where requireable paths that export plugins can be found
[x] before shipping, proof-of-concept an external promise plugin
[x] allow CLI users to easily unregister or move ahead/behind built-in plugins. I don't really want a new Teenytestfile type to explicitly specify all of them, but
it'd be nice to have control from day 1 for situations where order ends up mattering. Like append vs. prepend.
Or maybe the built-in modules should all have custom entry-points explicitly at the lifecycle phases so that they can't be thrown into a confusing state. this makes sense because some like results will change how subsequent wrappers get called
but it'd also be nice for the user to be able to un-register any plugin, particularly if they don't want TAP13
This has been my hobby project for the last week. Still pretty half baked.
The tl;dr is that this PR rewrites teenytest to implement most of its user-facing logic into plugins (docs). The internal plugins are all defined here and loaded by the runner here.
This is a pretty drastic detangling of all the runner-time logic teenytest contained before, and should allow us to do things like have user-defined plugins which transform test functions like #14 with promises or a first-class reporter plugin (in lieu or in addition to the TAP13 one) as #15 wants.
$ teenytest --config some/requireable/pathwhich would in turn export a function registering what it needs with teenytest, and invoked by teenytest's runnerresultswill change how subsequent wrappers get called