Plugin registration API such that plugins are registered in the helper?

[jasonkarns]

Realizing that plugins are trivially registered via the CLI or package.json... However, the best part of teenytest is its conventional defaults. As such I want my CLI invocation to just be teenytest and I don't want to have to add a teenytest stanza to my package.json.

Alternatively, I'm thinking the ability to easily register plugins within the conventional test helper would be nice? (Likely this would really just be the facility to configure anything in teenytest, not just plugins.)

require('teenytest').plugins returns the plugin store, but plugins can't be registered until a run has begun. However, invoking the main exported function kicks off the run (which has technically already begun since we're in the helper file.)

Wondering if it makes sense for the test helper to have access to the currently in-process test run? I have lots of ideas here but they're all kinda kludgy. Has anyone else thought about this at all?

possible options:

• expose in-process test run on the main export (such that require('teenytest') during a run has access to manipulate the current configuration)
• allow the test helper to export a function that is invoked at the beginning of the run that can manipulate the configuration
• allow require('teenytest').plugins to reference an in-process test run. (I'm already confused as to why this is exported as it currently is, when it's really an ephemeral property instantiated during the run.)

[searls]

Mocha ran into similar ordering/timing problems with the myriad use cases which depended on the --require CLI flag prior to test run start. I suspect what you want is a meta-helper hook (beforeAnything) that is guaranteed to run before the test files are even gathered so that any of the half dozen plugin types can be supported.

I swear there's a way to accomplish what you want as-is, though. I need to go spelunk a bit.

[searls]

Ah, right, the closest example to this I have is in this example project:

https://github.com/testdouble/teenytest/blob/master/safe/fixtures/projects/customize-configurator/config/teenyfile.js

The configurator does indeed need to be specified in the package.json, but what if we just established a conventional path for it as well in a minor bump? That way you could have a conventional hook for plugin registration

[searls]

A PR would probably amount to setting this to something and potentially guarding against its absence:

teenytest/lib/configure/defaults.js

Line 8 in fc2bd4b

configurator: null,

I have no idea what I'd call it, though. Suggestions?

[jasonkarns]

Perhaps? I was kinda thinking that we could just have plugins be exported from the conventional test-helper along with beforeEach, afterEach, etc.

[searls]

hmmm… I'm not necessarily opposed to that but I'm struggling to visualize. I'd personally like to keep "tests" and "config" separate, but I don't have a super clear reasoning