Multiple output-files / Allow extension of existing reporters

[steve-py96]

Clear and concise description of the problem

Before going to the problem I have to... Thank for this awesome lib, you're doing an insanely great job 👍🏿

The problem:
I have the case where I need the json and junit reporter at once (one dataset goes into some documentary, the other to gitlab), when using both they merge their results into the specified outputFile. Since I cannot access the default reporter classes (https://github.com/vitest-dev/vitest/blob/main/packages/vitest/src/node/reporters/json.ts f.e.) to overwrite some stuff I'd need to create a custom one by merging junit & json reporters which seems kinda cubersome.

(sidenote: if the FR is not declined I'd try to contribute to this ofc, if I may :P)

Suggested solution

If outputFile would accept a Record in a format like { [reporter]: outputFilePath } (besides the string, the simple solution should ofc remain for the simple cases :D) the reporters could be run in parallel (would result in code like this.ctx.config.outputFile.json || this.ctx.config.outputFile or typeof this.ctx.config.outputFile === 'string' ? this.ctx.config.outputFile : this.ctx.config.outputFile.json or sth).

Alternative

By exposing the default reporters somehow they could be overwritten (would result in code like class MyCustomReporter extends JsonReporter { ... } where the ctx could be overwritten at a certain point).

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[sheremet-va]

I like the suggested solution, if you can make it work 🤔

[ericjgagnon]

I'm in the process of creating a Jetbrains run/debug configuration plugin for Vitest that would require me to create a custom reporter to emit messages in a format that the plugin framework understands.

@sheremet-va would you be open to me creating a PR for @steve-py96 alternative solution? I'd love to bring first class support for Vitest to Jetbrains IDEs.

[AriPerkkio]

If outputFile would accept a Record in a format like { [reporter]: outputFilePath } (besides the string [...]

How could we use this with custom reporters? Currently the reporters option only allows class declarations, e.g. new SonarReporter().

Maybe it should allow package names of custom reporters as keys there. Vitest should then check if it's built in one - if not, import the given package and initialize it. Something similar as built-in ones have here:

vitest/packages/vitest/src/node/reporters/index.ts

Lines 11 to 19 in 978d37c

	export const ReportersMap = {
	'default': DefaultReporter,
	'verbose': VerboseReporter,
	'dot': DotReporter,
	'json': JsonReporter,
	'tap': TapReporter,
	'tap-flat': TapFlatReporter,
	'junit': JUnitReporter,
	}

This id could then also be used when declaring reporters from CLI, e.g. vitest run --reporters vitest-sonar-reporter. Currently this CLI API only allows built-in ones.

Maybe this first PR should only address the built-in reporters. I'm happy to help extending this functionality to cover custom 3rd party reporters.

[AriPerkkio]

Right, the custom reporters would actually work with the suggested changes. Simply with outputFile: { 'my-custom-reporter': 'some/path.xml' }, and in code this.ctx.config.outputFile['my-custom-reporter'].
I think I was mixing this with reporters configuration. 😄

[steve-py96]

@AriPerkkio was thinking about the CLI too tho, the --outputFile arg only allows 1 path after all... It'd make sense to limit this feature to a config but also it'd make sense to allow multiple outputFile args and attach them in proper order to the provided reporters f.e., idk what to prefer

[sheremet-va]

@AriPerkkio was thinking about the CLI too tho, the --outputFile arg only allows 1 path after all... It'd make sense to limit this feature to a config but also it'd make sense to allow multiple outputFile args and attach them in proper order to the provided reporters f.e., idk what to prefer

We can use dot-nested options: https://github.com/cacjs/cac#dot-nested-options

[sheremet-va]

@sheremet-va would you be open to me creating a PR for @steve-py96 alternative solution? I'd love to bring first class support for Vitest to Jetbrains IDEs.

Yeah, I think it's ok if we export default reporter for extending it's functionality, from vitest/node

[steve-py96]

Didn't check the used CLI lib, neat stuff 👌🏿
Adding that to the documentation later

[ericjgagnon]

@AriPerkkio @sheremet-va I have something working, similar to what @AriPerkkio mentioned:

Maybe it should allow package names of custom reporters as keys there. Vitest should then check if it's built in one - if not, import the given package and initialize it. Something similar as built-in ones have here...

To clarify this is for the CLI. The only issue I'm having at the moment is where to put tests for the added functionality? I don't really see any tests related to the CLI part of the vitest package. Do either of you have a preference? I want to make sure I have the go ahead and a test in place before putting in a PR.

[sheremet-va]

What do you mean? Don't we already have PR for this feature? I was waiting for @steve-py96 to make last changes before merging.

[ericjgagnon]

@sheremet-va there has definitely been a mixup, potentially by me. I'm going to open a separate enhancement request to describe my scenario in detail.

[steve-py96]

@sheremet-va sorry it was done already! I somehow managed to not push :(, it is up now