22 Replies
type.schema(type.boolean.json)
although it will fail for non-serializable constraints
You also probably have to cast the input for now
type.schema(type.boolean.json as never)
or something since it's not officially supported because of the serializability issueGitHub
How to construct a new Type from an exiting Type's internal JSON re...
Related to #1225 & #818 Type.toJSON()/.json return an internal representation of that type, parsed and reorganized from what is passed to `type(): const device = type({ platform: "'and...
awesome -- thank you!
i've got a possible bug -- going to open an issue for it, but wanted to double check here to make sure it isn't just user error on my part
https://stackblitz.com/edit/vitest-dev-vitest-ddhwwn9j?file=test%2Frepro.test.ts
andrew jarrett
StackBlitz
arktype union possible bug repro - StackBlitz
Run official live example code for Vitest Basic, created by Vitest Dev on StackBlitz
tl;dr
not sure why the range constraint would change the behavior there.
also not sure why, but the
[type.undefined]
is necessary too
this doesn't come from an actual use case, this was a generated schemaYeah that does look like a bug
cool. i'll raise the issue. unless you'd prefer i put it on reddit??
hah 😭 that shit
It probably has something to do with discrimination
cool. thanks for everything you do!
I will probably see if I can fix this now, hopefully relatively simple 🙏
oh wow, i haven't seen the playground until now. nice!
Ahh interesting, I see the issue
This is the discriminant
The problem is that in this case,
default
is equivalent to undefined
, so the default case is never hithttps://github.com/arktypeio/arktype/issues/1440
default means default discriminant? not like, default value?
This whole thing represents the way the discrimination works
i.e. check the value at path
[0]
, then depending on which case it ===
, apply the remaining checks
But the combination of the array + tuple leads to a bad result heregotcha. yeah it'd be a pretty strange schema to write by hand
Definitely a good case to fix though! Glad you caught it
Oh the ...s make the example a bit more confusing
This is the full case. I'm glad it gets the possibility of
null[]
having the value undefined

So the only problem is that
default
also needs to be grouped with undefined
heretbh, i'm not sure i understand hah. specifically i think the
{ undefined: [{ sequence: { prefix: [{ unit: 'undefined' }] } }] }
bit is confusing meIt's saying if the value at
0
is undefined, , check that the root value is either [undefined]
or a null[]
(int his case it would have to be []
)
But actually this discriminant is degenerate because once you include false
you haven't discriminated anythingIn the other case, it falls back to a better discriminant at the root of the type

oh okay, that makes more sense. cool
i've got a workaround here locally, but i'll follow that issue so i know when i can rip it out