vitest-dev/vitest · error · Error

Cannot create a benchmark project because the name "${name}"

Error message

Cannot create a benchmark project because the name "${name}" is already in use.

What it means

expandBenchmarksInEntries (resolveProjects.ts:797-801) injects a benchmark variant per benchmark-enabled entry, naming it `${parentName} (bench)` (or just 'bench' for unnamed projects). If that derived name is already in the `names` set (used by another project, browser instance, or an earlier benchmark variant), it throws.

Source

Thrown at packages/vitest/src/node/projects/resolveProjects.ts:800

 */
function expandBenchmarksInEntries(
  entries: ResolvedProjectEntry[],
  names: Set<string>,
  benchmarkOnly: boolean,
): ResolvedProjectEntry[] {
  let lastGroupOrder = Math.max(0, ...entries.map(e => e.projectConfig.sequence.groupOrder))
  const result = [...entries]

  for (const entry of entries) {
    const benchmark = entry.projectConfig.benchmark
    if ((!benchmark.enabled && !benchmarkOnly) || entry.hidden) {
      continue
    }

    const name = entry.projectConfig.name ? `${entry.projectConfig.name} (bench)` : 'bench'

    if (names.has(name)) {
      throw new Error(`Cannot create a benchmark project because the name "${name}" is already in use.`)
    }
    names.add(name)

    const benchmarkConfig: ResolvedConfig = {
      ...entry.projectConfig,
      name,
      include: benchmark.include,
      exclude: benchmark.exclude,
      includeSource: benchmark.includeSource,
      coverage: {
        ...entry.projectConfig.coverage,
        enabled: false,
      },
      maxWorkers: 1,
      maxConcurrency: 1,
      testTimeout: entry.projectConfig.testTimeout < 60_000 ? 60_000 : entry.projectConfig.testTimeout,
      hookTimeout: entry.projectConfig.hookTimeout < 120_000 ? 120_000 : entry.projectConfig.hookTimeout,
      // `enabled` because the original entry might not be benchmark-enabled (when

View on GitHub (pinned to d568f8ce37)

Solutions

  1. Rename the offending project so its `${name} (bench)` variant is unique.
  2. Avoid naming a project 'bench' when running in benchmark mode.
  3. Run benchmarks on a subset with --project to dodge the collision.
  4. If two source projects collide only in benchmark mode, give them distinct names.

Example fix

// before: a project named 'bench' plus --benchmark flag
// 'bench' (bench) collides with the unnamed 'bench'

// after: rename the source project
class Project { name = 'perf-core' } // variant becomes 'perf-core (bench)'
Defensive patterns

Strategy: validation

Validate before calling

const benchNames = entries.filter(e => e.benchmark.enabled).map(e => e.name ? `${e.name} (bench)` : 'bench')
if (new Set(benchNames).size !== benchNames.length) throw new Error('Benchmark variant name collision; rename source projects')

Type guard

function noBenchCollision(names: string[]): boolean {
  const bench = names.map(n => n ? `${n} (bench)` : 'bench')
  return new Set(bench).size === bench.length
}

Prevention

When it happens

Trigger: Two projects whose names both yield the same `${name} (bench)`; a project literally named 'bench' alongside an unnamed benchmark project; a previous benchmark variant occupying the name; --benchmark forcing every project to spawn a variant that collides.

Common situations: Running with --benchmark across projects where one is already named 'something (bench)'; a project named 'bench' colliding with the unnamed default; benchmark and browser expansion both targeting the same derived label.

Related errors


AI-assisted analysis of vitest-dev/vitest@d568f8ce37 (2026-08-03). Data as JSON: /data/errors/e5acc0bfb140fd6d.json. Report an issue: GitHub.