阅读中文版本

Parallelize Vitest Across Threads

Tune the Vitest pool and per-file isolation so a large suite finishes faster without flaky shared-state failures.

export default {
  test: {
    pool: 'threads',
    poolOptions: { threads: { minThreads: 2, maxThreads: 4 } },
  },
};

export default {
  test: { isolate: true },
};

What this recipe does

Increase test parallelism with a worker pool while keeping isolation for tests that share resources.

A growing unit suite takes too long on CI, and simply adding workers introduces flaky failures.

Prerequisites

• Vitest configured
• A suite with mixed isolation needs
• CI with multiple cores

Procedure

1. Use the threads pool with a bounded worker count.

export default {
  test: {
    pool: 'threads',
    poolOptions: { threads: { minThreads: 2, maxThreads: 4 } },
  },
};

Expected result: Files run in parallel up to the worker cap, reducing wall-clock time.

2. Isolate files that mutate shared global state.

export default {
  test: { isolate: true },
};

Expected result: Each file gets a fresh module registry, preventing cross-file leakage.

How to confirm it worked

Run the commands above and confirm every expected result in order. If a step does not produce the stated output, use the troubleshooting notes before continuing. A passing run shows the suite finishes in less wall-clock time with zero new flaky failures across repeated runs.

Troubleshooting

New flaky failures appear — Turn isolation back on or split shared fixtures per worker.

CI runs out of memory — Cap maxThreads below the core count and reduce the concurrency of heavy suites.

Limitations

• Isolation costs startup time.
• Parallelism amplifies shared-resource bugs.
• Requires de-flaking before speedup helps.