fix(runner): ensure sequential suite overrides sequence.concurrent

[dsyddall]

Description

Fixes #6652

Currently, when running Vitest with the --sequence.concurrent CLI option or with the sequence.concurrent config option set to true, describe.sequential has no effect and tests run concurrently.

This PR fixes the issue by ensuring that passing { concurrent: false } to the options of a suite does not only cancel the effect of passing { concurrent: true } but causes { sequential: true } to be set on the options, so that when the value of options.sequential is checked in the task function, it overrides the value specified in the runner config.

The test that originally checked for this behaviour became invalid with changes to the runner in Vitest 2.0.0, so this PR also updates the test to correctly check for the behaviour in v2.0.0 onwards.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
• Ideally, include a test that fails without this PR but passes with it.
• Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

• Run the tests with pnpm test:ci.

Documentation

• If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

• Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

[hi-ogawa]

Thanks for the PR!
It looks like your issue went unnoticed since vi.setConfig({ sequence: { concurrent } }) is not supported properly (type is available but doc says this https://vitest.dev/api/vi.html#vi-setconfig) Can you also add a new test in test/config to cover the case like your repro?

[dsyddall]

Yes, that looks correct. It looks like this option was removed in the v1 documentation (there was no such restriction in the v0 documentation when the test was added). Per your suggestion, I'll update this PR to remove the existing test and replace it with one in test/config.

It looks like the existing test is the only usage of the sequence.concurrent config property - since the docs have specified that it shouldn't be used since v1, perhaps after replacing the existing test, we can also remove the sequence.concurrent property from the RuntimeConfig type?

[hi-ogawa]

we can also remove the sequence.concurrent property from the RuntimeConfig type?

Yeah, I think so. Can you confirm @sheremet-va?

[sheremet-va]

To me, this seems like a regression. The docs started mentioning it just for clarification purposes, the behaviour of setConfig never changed, but how the config is used might've changed. I don't see why it shouldn't work in principle 🤔

[hi-ogawa]

Maybe this is because config.sequence.concurrent is picked up too early in default suite?

vitest/packages/runner/src/suite.ts

Lines 208 to 212 in 7a0de0a

	function createDefaultSuite(runner: VitestRunner) {
	const config = runner.config.sequence
	const api = config.shuffle ? suite.shuffle : suite
	return api('', { concurrent: config.concurrent }, () => {})
	}

I think looking up config.sequence.concurrent could be delayed until describe(...) or it(...) are called and at that point we can use config.sequence.concurrent overwritten by vi.setConfig.

[netlify]

✅ Deploy Preview for vitest-dev ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	439a2ed
🔍 Latest deploy log	https://app.netlify.com/sites/vitest-dev/deploys/6709c902ea72ca0007e055a7
😎 Deploy Preview	https://deploy-preview-6653--vitest-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[dsyddall]

Okay, that makes sense - in that case, I'll leave the type as it is and I've updated the PR to replace the existing test with a new test in test/config, as suggested.

[hi-ogawa]

Thanks, nice tests!

We can investigate vi.setConfig({ sequence }) separately. I'll create a new issue later.