Why this got removed instead of deprecated
concurrent and sequential described the same thing from two directions. A test was either allowed to run concurrently with its siblings or it wasn’t, and sequential only ever meant “not concurrent.” Vitest’s own migration guide states the removal directly, in the section covering these removed options:
Vitest 5.0 removes the deprecated
test.sequential,describe.sequential, andsequentialtest options. Useconcurrent: falsewhen you need a test or suite to opt out of inherited or globally configured concurrency.
The redundancy is what made this a removal candidate rather than a permanent pair of options. The GitHub issue that proposed this change lists out the full set of ways Vitest let you express test concurrency, including combinations like { sequential: false }, and points out that having two independent flags that can contradict each other (is { concurrent: false, sequential: false } concurrent or not?) creates internal churn and reader confusion for no real benefit. Collapsing to one flag, concurrent, removes the ambiguity entirely.
Not a warning, an outright removal
This isn’t the usual deprecate-then-remove cycle where a warning gives you a
release or two of runway. test.sequential, describe.sequential, and the
sequential option object key are gone in Vitest 5.0. If your suite still
calls any of them, the upgrade breaks that suite immediately, not on some
future major version.
Fix it: switch to concurrent: false
Vitest’s migration guide documents the exact replacement pattern for all three removed forms. Each is a mechanical rename, not a behavior change.
test.sequential("example", async () => {
/* ... */
}); // BROKEN: test.sequential no longer exists in Vitest 5test("example", { concurrent: false }, async () => {
/* ... */
}); // FIXED: same effect, using the surviving optiondescribe.sequential follows the identical pattern:
describe.sequential("suite", () => {
/* ... */
}); // BROKEN: describe.sequential no longer exists in Vitest 5describe("suite", { concurrent: false }, () => {
/* ... */
}); // FIXED: same effect, using the surviving optionIf your code used the sequential option-object key instead of the chained method, the same replacement applies directly to that key:
test("example", { sequential: true }, async () => {
/* ... */
}); // BROKEN: sequential key no longer recognizedtest("example", { concurrent: false }, async () => {
/* ... */
}); // FIXED: negate the surviving flag insteadSearch your suite for .sequential( and sequential: before you upgrade, not after. Every match needs this exact rename, and there’s no runtime compatibility shim carrying the old name forward.
Confirmed version range
Documented in Vitest’s own current migration guide as an intentional Vitest 5.0 removal, in the section covering the removed sequential options. Corroborated by vitest-dev/vitest#10180, the issue that proposed consolidating concurrency into the single concurrent flag. This repository’s own vitest.config.ts is pinned to vitest@^3.0.0, so this removal wasn’t independently reproduced against this project’s build; every claim above traces back to Vitest’s migration guide and the linked issue, not a local repro.
More fixes like this one are in the Guides & Fixes archive, and every Vitest post is tagged under vitest. If your suite is also hitting the hoisted-mocking change in the same upgrade, see Fix Vitest 5 vi.mock Top-Level Scope Error. Running vitest from a subdirectory in the same upgrade? See Fix Vitest 5 Config Not Found in Parent Directory.







