[Danielchinasa]

Title:

fix: add options to invalid discriminator errors

Description:

## Summary

Restores the `options` field to invalid discriminator errors that was present in Zod 3 but missing in Zod 4.

## Changes

- Added `options: Array.from(disc.value.keys())` to invalid discriminator error in `schemas.ts`
- Updated English locale to display valid discriminator values in error message
- Updated snapshot test to reflect new behavior

## Before

```json
{
  "code": "invalid_union",
  "discriminator": "type",
  "message": "Invalid input"
}
```

After

{
  "code": "invalid_union",
  "discriminator": "type",
  "options": ["fruit", "vegetable"],
  "message": "Invalid discriminator value. Expected 'fruit' | 'vegetable'"
}

Testing

• All existing tests pass
• Updated snapshot test to reflect improved output
• Manually tested with example code

Fixes #5670

[pullfrog]

Low urgency. The runtime behavior is correct and the approach is sound. The main issue is a missing type definition update — options is populated at runtime but not declared on $ZodIssueInvalidUnionNoMatch, so TypeScript users can't access it without a type assertion.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ pullfrog.com ｜ 𝕏}

[colinhacks]

@pullfrog re-review

[pullfrog]

No new issues. Reviewed the following changes:

• Added readonly options?: util.Primitive[] to $ZodIssueInvalidUnionNoMatch so TypeScript users can access discriminator options without a type assertion

Prior review feedback:

• Declare options on $ZodIssueInvalidUnionNoMatch in errors.ts — addressed in b906dc8

  ^{｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[colinhacks]

Merged. Nice to have options back on the discriminator-mismatch case of discriminatedUnion — restores the v3 behavior and makes the default message actually actionable. Thanks for the follow-up declaring the field on the issue type too, so reading it doesn't require a type assertion 👍

Note: this comment was produced by an AI coding assistant.

[colinhacks]

Landed in Zod 4.4