0.29.7 - 0.31.0 vitest no longer writes to outputFile.junit

[cheshirecode]

Describe the bug

As title says, I recently upgraded from 0.29.4 to 0.31 and noticed that vitest coverage produces coverage folder without custom test results file.
Reproducible config in stackblitz link and here're the main lines:

    reporters: ['default', 'junit'],
    outputFile: {
      junit: './coverage/junit.xml',
    }

The success message was printed during test runs

JUNIT report written to /local/data/scratch/trandf/projects/legion-ui/coverage/junit.xml
 % Coverage report from c8

but junit.xml is not there

> ls coverage/
base.css             clover.xml           favicon.png  prettify.css  sort-arrow-sprite.png  src
block-navigation.js  coverage-final.json  index.html   prettify.js   sorter.js

Once I downgraded to 0.29.7, the test results are there again.

Reproduction

https://stackblitz.com/edit/vitest-dev-vitest-9cocmu?file=vite.config.ts&initialPath=__vitest__

System Info

System:
    OS-CPU: Linux Redhat 7.9
    Memory: 1.10 GB / 15.51 GB
    Container: Yes
    Shell: 4.2.46 - /bin/bash
  Binaries:
    Node: 16.15.0 - ~/nodejs/16/bin/node
    npm: 8.5.5 - ~/nodejs/16/bin/npm

Used Package Manager

pnpm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[stackblitz]

Start a new pull request in StackBlitz Codeflow.

• vitest-dev-vitest-9cocmu (Open reproduction)

[AriPerkkio]

The JUnit test report is placed in coverage directory. When Vitest's JUnit reporter starts up it opens a file handle there. Next the coverage provider starts and cleans the old coverage reports by removing the coverage folder. This creates a conflict as coverage reporter did not expect anyone else to use its directory.

This is unintentionally caused by #3131

vitest/packages/vitest/src/node/core.ts

Lines 288 to 291 in 9836ccb

	await this.report('onInit', this)
	await this.initCoverageProvider()
	await this.coverageProvider?.clean(this.config.coverage.clean)

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

Lines 79 to 91 in 9836ccb

	async onInit(ctx: Vitest): Promise<void> {
	this.ctx = ctx
	const outputFile = getOutputFile(this.ctx.config, 'junit')
	if (outputFile) {
	this.reportFile = resolve(this.ctx.config.root, outputFile)
	const outputDirectory = dirname(this.reportFile)
	if (!existsSync(outputDirectory))
	await fs.mkdir(outputDirectory, { recursive: true })
	const fileFd = await fs.open(this.reportFile, 'w+')

Before 0.31.0 this was working but I don't think it was ever meant to be supported this way. Anyway, I think we should check whether this could be supported easily. Placing test reports in coverage directory seems to be common practice even though it's unexpected.

[AriPerkkio]

As work-around for now you can simply place the test report outside coverage report directory:

    reporters: ['default', 'junit'],
    outputFile: {
-      junit: './coverage/junit.xml',
+      junit: './any-other-directory/junit.xml',
    }

[cheshirecode]

Yeah that's what I suspected, and am placing output in a tmp folder now and manually copying it back to coverage folder since my current CI flow (outside my control) expects a specific directory like coverage. This may create an unintended and confusing pitfall if we customise coverage location as well:

    coverage: {
      reportsDirectory: './custom-coverage'
    },
    reporters: ['default', 'junit'],
    outputFile: {
      junit: './custom-coverage/junit.xml',
    }

May I suggest either:

1. (ideal wishful thinking) The sequence be reversed that coverage provider cleans and creates new coverage folder first, followed by custom reporters?
   OR
2. (easy quick fix) Error be thrown if (existsSync(outputDirectory)) like expecting custom reporter results in a different folder from coverage location

Happy to take a look and create a PR for this if you think it's okay but don't have the time.

[AriPerkkio]

May I suggest either:

(ideal wishful thinking) The sequence be reversed that coverage provider cleans and creates new coverage folder first, followed by custom reporters?

This first option sounds better. So the order would be reversed to be exactly as it was before #3131.

But we'll still need to have report('onInit') to be run even if initCoverageProvider() fails, as #3131 attempted to do. So I think following change could achieve both requirements here:

- await this.report('onInit', this)
+ try {
    await this.initCoverageProvider()
    await this.coverageProvider?.clean(this.config.coverage.clean)
    await this.initBrowserProviders()
+ }
+ finally {
+ await this.report('onInit', this)
+ }