arktype•4mo ago

ToJsonSchema fails with narrow

Hi short question, i might be missing something obvious. If I try to convert a type to jsonschema with a narrow function it fails every time, even if I use the .in property.

const url = type("string")
        .narrow((s, ctx) => {
            if (isValidHttpUrl(s)) {
                return true;
            }

            return ctx.mustBe("a valid URL");
        });

// FAILS:
url.in.toJsonSchema()

// EXPECTED:
{ type: 'string' }

const url = type("string")
        .narrow((s, ctx) => {
            if (isValidHttpUrl(s)) {
                return true;
            }

            return ctx.mustBe("a valid URL");
        });

// FAILS:
url.in.toJsonSchema()

// EXPECTED:
{ type: 'string' }

21 Replies

ssalbdivad•4mo ago

What does the error message say?

MöhreOP•4mo ago

Uncaught ParseError: Predicate $ark.fn19 is not convertible to JSON Schema

ssalbdivad•4mo ago

Well it makes sense right? It's saying you have a condition on your type that can't be represented in JSON schema so it fails

MöhreOP•4mo ago

I guess but i thought the in property takes the input types which would be string

ssalbdivad•4mo ago

Maybe at some point there will be a "loose" toJsonSchema where if there are custom predicates (you narrow your type) it will strip them out, but that doesn't exist yet. Anything you can use a regex for can be converted directly It takes the input type of your transformation, but narrowing is not a transformation it's just an assertion

MöhreOP•4mo ago

I know atleast for the url there is a type, was just an example. Would pipe work for that?

ssalbdivad•4mo ago

Yeah if you pipe it to itself but do the extra check there, then you can extract .in, it would work

MöhreOP•4mo ago

I see, thanks for the clarification. A kinda loose or lax mode for that would be very helpful!

ssalbdivad•4mo ago

Feel free to create an issue! Would definitely be interested in adding that at some point or accepting contributions

MöhreOP•4mo ago

Allright!

Randall•4mo ago

So narrow can make a type break jsonschema. Morph OK? Sometimes names help clarity. Restrict, narrow, transform, morph, validate,... thesaurus. X like y& lax semantic Any AT constructs that can feed jsonschema native constraints? OK to rtfm me, night here rn

ssalbdivad•4mo ago

I don't know if this was intentionally ironic but this is so hard to understand 😅

Randall•4mo ago

Phone kb sry

ssalbdivad•4mo ago

You don't just have to rely on naming just think "can this thing be represented in JSON schema"? If it's a custom function or symbol or something it can't, there are clear errors

Randall•4mo ago

'Course Will rety later What I was trying to say was that a) I understand using narrow() screws up the chance to represent a type as JSON-Schema. b) I'm assuming morph works fine, not affecting the JSON-Schema output. c) I wonder if some variant fitting between those two somehow could express a type that produces a valid JSON-Schema, while still capturing the functionality restricting actual data in ways that would raise (post-schema) validation failures. Just as morph could explode if it sees something it doesn't like, and recognizing that not every possible constraint/restriction/transform/validate may be expressible within JSON-Schema's capabilities, yet still be fundamentally part of the data's domain model. d) those ...names could be ideas for how to name an API call expressing such facts about the domain model. and finally e) I'm assuming that basic min/max constraints "< 4" would be representable in JSON-Schema (are they?) ... and others?

ssalbdivad•4mo ago

Yeah anything that is built into JSON schema like min/max regex is translated You're not quite right about morphs They can't be represented as JSON schema But you can extract one side of them and then translate that Narrows, it's trickier. It's part of the type itself. If it was removed it would be fundamentally different

Randall•4mo ago

that's intuitive

ssalbdivad•4mo ago

But there are other non-serializable conditions so it's not unique in that regard For example, if you had a type === symbol or instanceof MyConstructor, those would not be translatable either So the best thing I can do is throw an error if you try to convert something like that to JSON schema. In the future, there's been discussion about a loose mode which would allow configurably ignoring certain constraints so you could still get the shape But being strict by default I think makes sense

Randall•4mo ago

so laxNarrow , lateNarrow, constraint etc ... all just thesaurifying a way of reframing the notion of "loose". Not sure if it buys people anything by way of different granularity. relax this case.

ssalbdivad•4mo ago

I wouldn't change anything about the API for defining constraints I'm saying I could add an option you'd pass to toJsonSchema that would ignore those things

Randall•4mo ago

heard thanks for this heavy duty work

Gaming

Programming

ToJsonSchema fails with narrow