ssalbdivad Comments - Answer Overflow

Topics

ssalbdivad

•Created by Bo on 3/27/2025 in #questions

How to use reject correctly?

As a workaround try this:

type("File | File[] < 6").pipe(data => data).narrow(...

type("File | File[] < 6").pipe(data => data).narrow(...

This way it won't treat the second part of the validation as a union

19 replies

•Created by Bo on 3/27/2025 in #questions

How to use reject correctly?

That definitely could be improved if you want to create an issue for that.

19 replies

•Created by Bo on 3/27/2025 in #questions

How to use reject correctly?

Oh it's because it's a union error so it can't use the individual actual for that specific error

19 replies

•Created by Bo on 3/27/2025 in #questions

How to use reject correctly?

Have you read these docs? https://arktype.io/docs/configuration#errors

19 replies

•Created by Bo on 3/27/2025 in #questions

How to use reject correctly?

Yeah it should never crash unless you're passing in something that isn't allowed by the type signature

19 replies

•Created by Bo on 3/27/2025 in #questions

How to use reject correctly?

If you can upload a minimal repro somewhere I will look into the crash which shouldn't happen

19 replies

•Created by Bo on 3/27/2025 in #questions

How to use reject correctly?

I wasn't able to repro that crash, could you paste the full code? If what you mean is you want errors for individual files even is more than 6, you can add this to the array case:

        if (data.length < 6) {
            ctx.error({ code: "maxLength", rule: 6 })
        }

        if (data.length < 6) {
            ctx.error({ code: "maxLength", rule: 6 })
        }

If shallow validation fails (E.g. array length), nested validation doesn't run

19 replies

•Created by log1st on 3/26/2025 in #questions

Issue with Default<> in Type as generic.

But almost all the actual error context is encoded in each ArkError so you should be fine

15 replies

•Created by log1st on 3/26/2025 in #questions

Issue with Default<> in Type as generic.

It is new! I added it a couple releases ago to allow serializing errors. You can push new errors to the ArkError[], you just can't use methods like .add that collapse errors at common paths on ArkError. That fundamentally wouldn't make sense to deserialize since ArkErrors is supposed to be associated with a single data validation traversal

15 replies

•Created by log1st on 3/26/2025 in #questions

Issue with Default<> in Type as generic.

It wouldn't usually make sense to add new errors to a serialized/deserialized error list

15 replies

•Created by log1st on 3/26/2025 in #questions

Issue with Default<> in Type as generic.

What are you wanting to do exactly you can't do with an ArkError[]?

15 replies

•Created by log1st on 3/26/2025 in #questions

Issue with Default<> in Type as generic.

Hmm I haven't built anything yet but it's basically an identical structure to ArkErrors. Technically ArkErrors has some non-serializable stuff like a Traversal for the current data being checked that provides context for errors, so that would not be deserializable. I think you could just JSON.parse() it and cast to ArkError[] ?

15 replies

•Created by log1st on 3/26/2025 in #questions

Issue with Default<> in Type as generic.

Yes! I added a toJSON() method so you can use that (it will happen by default if you JSON.stringify them)

15 replies

•Created by log1st on 3/26/2025 in #questions

Issue with Default<> in Type as generic.

That is a weird issue! It seems like TS prefers if the type is inferred as a whole:

export const generic = <t extends type>(filter: t) =>
    type({
        take: "number.integer = 10",
        filter: filter as type.cast<t["t"]>
    })

const example = generic(
    type({
        slug: `string = "defaultSlug"`
    })
)

export const generic = <t extends type>(filter: t) =>
    type({
        take: "number.integer = 10",
        filter: filter as type.cast<t["t"]>
    })

const example = generic(
    type({
        slug: `string = "defaultSlug"`
    })
)

Or perhaps better yet, accept a definition so you don't have to wrap what you pass in (you can still pass in a type instance since they're also valid definitions:

export const generic = <const def>(filter: type.validate<def>) =>
    type({
        take: "number.integer = 10",
        filter: filter as type.cast<type.infer<def>>
    })

const example = generic({
    slug: `string = "defaultSlug"`
})

export const generic = <const def>(filter: type.validate<def>) =>
    type({
        take: "number.integer = 10",
        filter: filter as type.cast<type.infer<def>>
    })

const example = generic({
    slug: `string = "defaultSlug"`
})

15 replies

•Created by knthmn on 3/24/2025 in #questions

Type instantiation is excessively deep and possibly infinitely deep

Yes and yes

5 replies

•Created by knthmn on 3/24/2025 in #questions

Type instantiation is excessively deep and possibly infinitely deep

Yes, just add it to a prototypes config! https://arktype.io/docs/configuration#prototypes

5 replies

•Created by Josh on 3/24/2025 in #questions

Trying to index an array type with .get(...path)

Excited to see what you cook up!

37 replies

•Created by Josh on 3/24/2025 in #questions

Trying to index an array type with .get(...path)

You're right there are tons of ways you could do it because the internal type nodes are very introspectable. Maybe the best approach would be to decide the API you want first and exactly how you want the types to behave, then figure out how to get the values to do that

37 replies

•Created by Josh on 3/24/2025 in #questions

Trying to index an array type with .get(...path)

Like JSON

37 replies

•Created by Josh on 3/24/2025 in #questions

Trying to index an array type with .get(...path)

You can have optional properties but know that undefined will never actually be a possible value of a present key

37 replies