arktype•4w ago

Stanard Schema issues conformance

Hello! As I've been playing with Tanstack Start, it seems that there's an issue with how Arktype handles issues. Standard Schema defines, that issues should look like this:

/** The result interface if validation fails. */
export interface FailureResult {
  /** The issues of failed validation. */
  readonly issues: ReadonlyArray<Issue>;
}

/** The issue interface of the failure output. */
export interface Issue {
  /** The error message of the issue. */
  readonly message: string;
  /** The path of the issue, if any. */
  readonly path?: ReadonlyArray<PropertyKey | PathSegment> | undefined;
}

/** The path segment interface of the issue. */
export interface PathSegment {
  /** The key representing a path segment. */
  readonly key: PropertyKey;
}

/** The result interface if validation fails. */
export interface FailureResult {
  /** The issues of failed validation. */
  readonly issues: ReadonlyArray<Issue>;
}

/** The issue interface of the failure output. */
export interface Issue {
  /** The error message of the issue. */
  readonly message: string;
  /** The path of the issue, if any. */
  readonly path?: ReadonlyArray<PropertyKey | PathSegment> | undefined;
}

/** The path segment interface of the issue. */
export interface PathSegment {
  /** The key representing a path segment. */
  readonly key: PropertyKey;
}

However, arktype puts it's own errors in the issues, that do not conform to the above interfaces. It's troubling as serialization with JSON.stringify fails, as the ArkError seems to have circular reference to itself. Of course, validation was performed by invoking schema['~standard'].validate(value). CC: @Manuel Schiller

12 Replies

KubaOP•4w ago

For instance, valibot and zod return schema-conformant issues. Valibot:

KubaOP•4w ago

And Zod:

KubaOP•4w ago

Arktype returns ArkErrors which itself has issues getter function instead of an Array of Schema's Issue, and trying to serialize it results in an TypeError error:

Converting circular structure to JSON\n --> starting at object with constructor 'ArkErrors'\n | index 0 -> object with constructor 'ArkError'\n | property 'ctx' -> object with constructor 'Traversal'\n --- property 'errors' closes the circle

Converting circular structure to JSON\n --> starting at object with constructor 'ArkErrors'\n | index 0 -> object with constructor 'ArkError'\n | property 'ctx' -> object with constructor 'Traversal'\n --- property 'errors' closes the circle

ssalbdivad•4w ago

To be clear it certainly conforms to the schema which says nothing about serialization. That said, if you'd like to create a GitHub issue I can add a toJSON method or similar to make this smoother.

Manuel Schiller•4w ago

would it make sense to enhance the standard with this aspect? from a library point of view such as tanstack start we need to have them behave the same at runtime

ssalbdivad•4w ago

I mean all the properties specified in the spec do behave the same at runtime. You're just asking for them to be JSON-serializable which is a reasonable request. I don't think this would be a good fit for the spec because it is not enforceable at an API level

Manuel Schiller•4w ago

yes that's what I would need here

ssalbdivad•4w ago

There was some related discussion about this here with a similar conclusion: https://github.com/standard-schema/standard-schema/issues/49 I will prioritize adding a toJSON method for 2.2

GitHub

How to handle throwing validation errors for any validation library...

I have an API router that you can pass schemas to for validating various data types; e.g. json in the request body. The dev can pass in the schema, then I'm using code inside my router to do th...

ssalbdivad•4w ago

https://github.com/arktypeio/arktype/issues/1352

GitHub

JSON serializable ArkErrors · Issue #1352 · arktypeio/arktype

Would make some Standard Schema integrations easier, see standard-schema/standard-schema#49

KubaOP•4w ago

It's true that the standard doesn't say anything about the serialization. Until now I though that all errors are serializable, but I didn't ever account that error can have references to itself. Of course don't take it as offence or critique, it more an interesting observation and something new to me. Hey @ArkDavid, I have an update. It was decided with the Tanstack maintainers that instead of stringifying the errors with JSON, it might be a better approach to extract the message and path, which the spec guarantees to be present on Issue. It's motivated by the though that if any of validation libraries has non-serializable issues, then utilizing just the mentioned fields avoids this issue altogether. I felt that this thread put a bit of unnecessary urgency on you to prioritize the toJSON support. From the perspective of Tanstack libraries this shouldn't be as critical anymore in the nearby future, so there’s no need to prioritize it as highly as we initially thought.

ssalbdivad•4w ago

Hey thanks for letting me know and I definitely appreciate the thoughtfulness of the message as well! A simple JSON mapping that extracts the most important parts of the error would be trivial to build and useful anyways, so I'm still planning to release it in 2.2 😊

KubaOP•4w ago

No problem! 😃 That sounds promising, looking forward to the release of it, but no pressure with the timeline here

Gaming

Programming

Stanard Schema issues conformance

Did you find this page helpful?