fix(schema): avoid JSON.stringify crashes on ArkErrors issues slots

[gabroberge]

Summary

• Set ArkErrors[Symbol.species] to Array so inherited array methods (map, filter, slice, …) allocate a plain Array, not another ArkErrors. This fixes the case where issues.map(issue => issue.message) could return an ArkErrors whose numeric indices held strings (callback results), which then broke JSON.stringify with TypeError: e.toJSON is not a function inside ArkErrors.prototype.toJSON.
• Add regression tests: Symbol.species / map → Array, plus a Standard Schema failure path that **JSON.stringify**s a realistic HTTP-style payload ({ issues, messages }).

How the problem shows up

1. On validation failure, schema["~standard"].validate returns an ArkErrors instance; issues is the same value (an Array subclass).
2. Without [Symbol.species], issues.map(…) allocates another ArkErrors, filling indices 0..n-1 with callback return values (e.g. strings from issue.message), not ArkError instances.
3. That value can end up in an HTTP error payload passed to JSON.stringify. ArkErrors defines toJSON, so serialization invokes ArkErrors.prototype.toJSON even when numeric slots are no longer ArkError objects.
4. ArkErrors#toJSON does this.map(e => e.toJSON()) — strings have no toJSON → TypeError: e.toJSON is not a function, often surfacing as a server error while building the response body instead of a stable client error JSON payload.

How this change fixes it

static get [Symbol.species](): ArrayConstructor { return Array } — array methods that create a new array now yield a normal Array, so issues.map(issue => issue.message) returns a plain array of strings. JSON.stringify on issues itself still goes through ArkErrors#toJSON and serializes ArkError instances as before; the failure mode was specifically map (and similar) reusing the subclass constructor for the result.

Test plan

• Array methods allocate plain Array (Symbol.species), not ArkErrors
• JSON.stringify round-trip via Standard Schema failure (e.g. HTTP error payload)

[pullfrog]

The fix itself is correctly implemented and the branching logic is sound, but the motivating scenario relies on bypassing ArkErrors's ReadonlyArray typing via an as unknown as { push } cast — there is no public path through ArkType that lands a non-ArkError in this array. Before adding a permanent defensive serializer to a hot, public surface, it would help to see a real-world reproduction that produces the TypeError without forcing the cast (e.g. a Standard Schema consumer that legitimately ends up with heterogeneous issues from ArkType output).

TL;DR — Hardens ArkErrors#toJSON so JSON.stringify no longer throws TypeError: e.toJSON is not a function if the array contains entries that don't implement toJSON, and adds a regression test.

Key changes

• Defensive indexed-issue serializer — ArkErrors#toJSON now routes each entry through a new private indexedIssueToJson helper that branches on the entry's shape instead of assuming every element is an ArkError.
• Regression test — pushes a plain { message, path } object into an ArkErrors instance and asserts JSON.parse(JSON.stringify(errors)) round-trips both entries.

_{Summary ｜ 2 files ｜ 1 commit ｜ base: main ← fix/arkerrors-tojson-heterogeneous-issues}

Tolerating non-ArkError entries in toJSON

Before: toJSON mapped each entry with e.toJSON(), throwing if any entry lacked the method.
After: Each entry is routed through indexedIssueToJson, which handles undefined / null / non-objects / objects with toJSON / { message, path } shapes / fallback String(issue).

The branch order is sensible and preserves existing ArkError behavior via toJSON.call(issue). The crash described in the PR body, however, requires (errors as unknown as { push }).push(...) — ArkType's own code only inserts via add(error: ArkError), so a real reproduction path from Standard Schema usage would strengthen the case for keeping this defensive code long-term.

ark/schema/shared/errors.ts · ark/schema/__tests__/errors.test.ts

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[ssalbdivad]

Great, this was a huge footgun thanks so much for the thoughtful fix ❤️