Add `--reporters` argument about runner

[thetutlage]

Great proposal. I see two things here.

• We need the reporters array to be a collection of reporters, where all of the reporters are not enabled by default. Or in other words, they are disabled by default.
• Next, we can activate one or more reporters with the --reporters flag.
• Finally, we need at least one default enabled reporter. Otherwise, it becomes tiring to always pass the --reporter flag.

I was looking at Mocha, and they have the spec reporter enabled by default. However, the spec reporter is bundled within mocha, so they always have it available.

Have you looked at Vitest or Jest, how they approach this? I have some ideas in mind, but let's see if there is an established pattern

[Julien-R44]

Yes, so Vitest proposes a bit the same thing as my last suggestion. Except that all the reporters are built-in and directly integrated in it. No additional packages to install :
https://vitest.dev/config/#reporters

Jest proposes this :
https://jestjs.io/fr/docs/configuration#reporters-arraymodulename--modulename-options

I am personally not a fan of Jest's tuple syntax, and I find Vitest's approach much more clear and concise.
However, the problem with Vitest's approach is that it is impossible to change reporter options. We could imagine a reporterOptions property, but this would not be typesafe :

configure({
   reporter: 'dot',
   reporterOptions: {
      dotOption: true
   }
})

[thetutlage]

How about making reporters an object with following properties.

reporters: {
  list: [],
  default: 'spec',
},

The default property can be type safe based upon what's in their in the list.

[Julien-R44]

The problem with this solution is that you can't activate several reporters at the same time unless you use the --reporters flag. But I ask again: do we really need to activate several reporters at the same time?

Or maybe we can just make it an array :

reporters: {
  list: [],
  default: ['spec','another'],
},

[Julien-R44]

Actually yes, having multiple reporters can be handy. Let's imagine that the user wants to have a json reporter that saves the result of the tests in a file but doesn't display anything in the console, but also to have the spec reporter. This is a bit of a stretch, but it could make sense

[thetutlage]

Yeah, we can allow the default one to be an array and rename the property to be defaults.

So basically, you have a hardcoded set of defaults in the config. However, you can overwrite them using the --reporters flag

[Julien-R44]

Okay, that sounds nice. The only thing that bothers me a little is that it results in a breaking change. But at this point, I don't think we have much choice if we want to offer an API that's not too ugly

If it sounds okay for you, I'm willing to implement it this weekend

[Julien-R44]

Let me just recap:

• We forget about the non breaking change attempt on the ReporterContract knowing that we have another breaking change, so not much interest except being error prone.
  This means that the contract of the reporter becomes the following :

type ReporterContract = 
   | { name: string; handler: ReporterHandler } 
   | ReporterHandler

• Then, as you said, we keep that API for the configure function :

reporters: {
  list: [
     specReporter(),
     anotherReporter()
   ],
  defaults: ['spec','another'],
},

As simple as that !

[Julien-R44]

Actually, no, sorry. It is perfectly possible to make the thing non-breaking.

• We keep my suggestion about the ReporterContract.
• And finally, we do the same thing for the reporters configuration property. Basically: if reporters is an array, like in the current API, then we just enable all reporters. If it's an object, then we use the new system.

[thetutlage]

Right now we do not have many 3rd party reporters. So, we can break the ReporterContract and ship them as major server. People won't have to change a line in their config.

For the config reporters property, yes, it can be backwards compatible.

[Julien-R44]

Yeah, I was mostly thinking of people that would potentially write an inline reporter. Or who would have just kept their reporter private. Very unlikely to be the case honestly, but possible.

[thetutlage]

Yeah, but I think 0.1% chance of that. Also, we will mark it as a major release. Its just I do not want others to change their config too after the upgrade.

[Julien-R44]

Okay great. Thanks a lot for the feedback dude. I'll get right on it quickly!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.