Can validation errors be shortened?

[maurice]

Report a bug

In the below example the validation error is "sections must be { [string]: { authors: string[], isbn: string, publisher: { id: string, name: string }, title: string, subtitle?: string }[] } (was missing)".

Is there any way it could be "sections must be a valid Sections (was missing)" or maybe even better (IMHO) "sections must be present (was missing)", for example?

In the case of my real production app, the nested types are quite broad and deep, so the error is much longer. It would be nice if it could be shorter and more specific 🙏.

I'd be perfectly happy if there's a config option or function for this; I'm not requesting any change to the default behaviour (but it might be worth consideration?).

🔎 Search Terms

Minimal validation error referencing high-level type names instead of expanded type-tree.

🧩 Context

• ArkType version: 2.0.0-dev.21
• TypeScript version (5.1+): 5.4
• Other context you think may be relevant (JS flavor, OS, etc.):

🧑‍💻 Repro

playcode.io example

import { scope } from 'arktype';

export const types = scope({
    Library: {
        sections: 'Sections',
    },
    Sections: {
    '[string]': 'Book[]',
    },
  Book: {
    isbn: 'string',
    title: 'string',
    'subtitle?': 'string',
    authors: 'string[]',
    publisher: 'Publisher',
  },
  Publisher: {
    id: 'string',
    name: 'string'
  }
}).export()

console.log(types.Library({}).summary);
// => sections must be { [string]: { authors: string[], isbn: string, publisher: { id: string, name: string }, title: string, subtitle?: string }[] } (was missing)

[ssalbdivad]

@maurice Actually this is already planned in:

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

It used to be "was present" but I found in many circumstances, especially for primitives, it's more immediately helpful to see something like "must be a number (was missing)."

That said, this is obviously way too much detail. With this change, it will instead read "must be an object (was missing)" by default.

Keep in mind you can also configure how any object is described using a tuple expression like this:

    Sections: [
        {
            "[string]": "Book[]"
        },
        "@",
        "a valid Sections object"
    ],

Or in a standalone or chained type using .describe("a valid Sections objects").

This would give you the error message you want.

Defaulting objects in a scope to have a description matching their alias name would be worth considering, so feel free to create a feature request if you'd like that.

Sidenote, that type-syntax representation of the underlying type is pretty nice though, huh? 😛

[maurice]

Hi @ssalbdivad

Sidenote, that type-syntax representation of the underlying type is pretty nice though, huh? 😛

Yes absolutely - everything about arktype (brevity, resemblance to TS, performance) is premium 😍.

Keep in mind you can also configure how any object is described using a tuple expression like this

Ah, that’s fantastic, let me try this tomorrow!

I think this is where I personally struggle with arktype, ie, the discoverability of features. Probably because all my types are in one big scope which feels like a DSL vs (perhaps) standalone type(…)s. I think for me more examples in the docs might help although I appreciate you are busy and have 10 billion things to do that are not documentation!

FYI I’m using arktype to validate inbound (server to GUI) JSON messages vs an advertised (AsyncAPI) API doc and have been finding some interesting violations that without arktype we wouldn’t know about and could easily cause GUI crashes, so it’s helping us improve the stability of our app.

After this experience I now consider validation at the boundaries of an app to be a mandatory non-functional requirement.

[ssalbdivad]

@maurice That's awesome to hear!

Now that the 2.0 API is mostly stable, docs are my top priority and I'm working on getting everything covered as quickly as I can. Keep an eye on https://arktype.io in the next week as I add more content 📚