vitest-dev/vitest · error · Error

AssignmentPattern is not supported. Please open a new bug re

Error message

AssignmentPattern is not supported. Please open a new bug report.

What it means

Thrown at packages/mocker/src/node/automock.ts:115-118 by traversePattern when traversing an export destructuring pattern encounters an AssignmentPattern. Assignment patterns (`{ a = 1 } = obj`) represent default values in destructuring, which the automocker's static export collection does not support.

Source

Thrown at packages/mocker/src/node/automock.ts:116

            if (property.type === 'RestElement') {
              traversePattern(property)
            }
            // export const { test, test2: alias } = {}
            else if (property.type === 'Property') {
              traversePattern(property.value)
            }
            else {
              property satisfies never
            }
          })
        }
        else if (expression.type === 'RestElement') {
          traversePattern(expression.argument)
        }
        // const [name[1], name[2]] = []
        // cannot be used in export
        else if (expression.type === 'AssignmentPattern') {
          throw new Error(
            `AssignmentPattern is not supported. Please open a new bug report.`,
          )
        }
        // const test = thing.func()
        // cannot be used in export
        else if (expression.type === 'MemberExpression') {
          throw new Error(
            `MemberExpression is not supported. Please open a new bug report.`,
          )
        }
        else {
          expression satisfies never
        }
      }

      if (declaration) {
        if (declaration.type === 'FunctionDeclaration') {
          allSpecifiers.push({ name: declaration.id.name })

View on GitHub (pinned to d568f8ce37)

Solutions

  1. Provide an explicit vi.mock factory so automock parsing is bypassed.
  2. Refactor the target module to avoid default values in exported destructuring patterns.
  3. Mock only the specific named exports you need rather than the whole module.

Example fix

// target module (causes error when automocked):
// export const { port = 3000 } = loadConfig()

// fix in the test: provide a factory
vi.mock('./config', () => ({ port: 8080 }))
Defensive patterns

Strategy: validation

Validate before calling

// Detect default destructuring in exports of the target before automocking.
import { readFileSync } from 'node:fs'
function hasAssignmentPatternInExport(file: string): boolean {
  // crude heuristic: exported destructuring with an '=' default
  return /export\s+const\s*\{[^}=]*=[^}=]*\}/.test(readFileSync(file, 'utf-8'))
}

if (hasAssignmentPatternInExport('./config.ts')) {
  vi.mock('./config.ts', () => ({ port: 8080 }))
} else {
  vi.mock('./config.ts')
}

Try / catch

try {
  vi.mock('./config.ts')
} catch (e) {
  if (e instanceof Error && /AssignmentPattern is not supported/.test(e.message)) {
    vi.mock('./config.ts', () => ({ port: 8080 }))
  } else { throw e }
}

Prevention

When it happens

Trigger: Automocking (no factory) a module that contains an export with a destructuring default, e.g. `export const { count = 0 } = getConfig()` or `export const [first = 'x'] = items`.

Common situations: Automocking a config/util module that destructures exports with defaults; refactoring a module to use default destructuring breaks previously-working automocks.

Related errors


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