Expose internal events for custom reporters via config

[codetheweb]

We've been using a similar approach to this internally on a patched version of AVA for the last few weeks to pipe test runs to Datadog and it's been working great.

Alternatives:

• use a Shared Worker: I think the solution here is much simpler than introducing a third type of worker (Shared Workers, Test Workers, and Suite(?) Workers) and covers most use cases I can think of.
• use Diagnostic Channels: I'm not very familiar with this built-in, but looks like it could help reduce the performance impact of this?

This is very much still a draft, just wanted to get some initial feedback on whether this solution is ok before I continue down the path. Still need to:

• add TS definitions for internal events (maybe exposed under import type {AVAEvent} from "ava/internal" or something?)
• add additional tests

[novemberborn]

I agree that this is the easiest approach that can ship. I don't want to provide any SemVer guarantees to the internal event objects though. This should be an experiment requiring opt-in through the configuration (nonSemVerExperiments: { observeRunsFromConfig: true } } if I recall the syntax).

We've been using a similar approach to this internally on a patched version of AVA for the last few weeks to pipe test runs to Datadog and it's been working great.

Alternatives:

• use a Shared Worker: I think the solution here is much simpler than introducing a third type of worker (Shared Workers, Test Workers, and Suite(?) Workers) and covers most use cases I can think of.
• use Diagnostic Channels: I'm not very familiar with this built-in, but looks like it could help reduce the performance impact of this?

This is very much still a draft, just wanted to get some initial feedback on whether this solution is ok before I continue down the path. Still need to:

• add TS definitions for internal events (maybe exposed under import type {AVAEvent} from "ava/internal" or something?)
• add additional tests
• ensure errors in the user's event handler don't affect AVA

Shared workers survive across multiple test runs (when in watch mode) and so would be appropriate. It's just awkward that you have to launch them from a test worker and they could integrate better with the concept of a test run.

[codetheweb]

is there a scenario where api will emit run multiple times? (other than watch mode maybe?)

[novemberborn]

No, just in watch mode. May be helpful for the callback function to know that watch mode is active though.

[codetheweb]

👍 might be good to add as a future enhancement

[codetheweb]

apologies for the late replies!

happy to add more tests, but not sure what to look for

[novemberborn]

Sorry @codetheweb I've had very little time for open source lately.

[novemberborn]

This is looking pretty good, I've added some suggestions. A ton of care went into typing the state change events!

When it comes to additional testing, the good news is that for these "experimental" features the bar is a little lower, so this is pretty close to done IMHO.

[novemberborn]

No, just in watch mode. May be helpful for the callback function to know that watch mode is active though.

[novemberborn]

Looking good, bar the failing tests :)

[codetheweb]

a new rule started complaining about this, ava is always stylized AVA so I think it's ok to disable here?

[novemberborn]

I'd like to stick with the rule here. Will push up a commit.