ssalbdivad Comments - Answer Overflow

Topics

ssalbdivad

•Created by terinjokes on 11/4/2024 in #questions

morphing to typescript type

This is a known design limitation but unfortunately there is not a performant way to check for functions returning never specifically without incurring a lot of overhead for a fairly niche case. The same is true for functions returning any However, the ideal solution for problems like these is just for ArkType to treat it as a known builtin object and not recurse into it. I will add the temporal objects to the list of builtins once they're generally available, but for now you can add additional builtins to ignore during inference like this:

declare global {
    export interface ArkEnv {
        prototypes(): Temporal.ZonedDateTime | OtherKnownClasses
    }
}

declare global {
    export interface ArkEnv {
        prototypes(): Temporal.ZonedDateTime | OtherKnownClasses
    }
}

24 replies

•Created by dibbo on 11/3/2024 in #questions

Generic middleware validator

Could you create a repo from this so I can see it locally? I'm not seeing errors in the codesanbox, just a bunch of stuff falling back to any

6 replies

•Created by dibbo on 11/3/2024 in #questions

Generic middleware validator

Can you post the relevant types that are resulting in the errors? It seems like it would be some combination of use, handler, MiddlewareObj and ValidatedBody. You should not have to cast just because a schema is large unless it's so big arktype has a problem inferring it directly

6 replies

•Created by Dimava on 10/29/2024 in #questions

Compiling scope to interfaces

Yeah that should work

38 replies

•Created by Dimava on 10/29/2024 in #questions

Compiling scope to interfaces

But like I said in other cases if it doesn't work, it's very unclear what I could do to change it if the inference works in .ts but not in .d.ts that is really a transformation that typescript owns not me

38 replies

•Created by Dimava on 10/29/2024 in #questions

Compiling scope to interfaces

Right yeah that is what I'd expect but like I said you are duplicating a lot of the relationships + structures

38 replies

•Created by Dimava on 10/29/2024 in #questions

Compiling scope to interfaces

Yeah I don't get it all the references will be dynamic you'd have to respecify every type I don't see how .infer would help or what you're asking for

38 replies

•Created by Dimava on 10/29/2024 in #questions

Compiling scope to interfaces

Maybe you could add a scope.declare but it will come with it's own problems in addition to being duplicative

38 replies

•Created by Dimava on 10/29/2024 in #questions

Compiling scope to interfaces

Right, but it's just not geenerally possible in TS where each scoped type is dynamically computed and I can't associate a name with it

38 replies

•Created by Dimava on 10/29/2024 in #questions

Compiling scope to interfaces

I'm sure the TS team would appreciate it if 10% of the time you spent asking me for features was spent asking them to build them in a much more general and powerful way instead of me trying to hack around in a very limited way 😛

38 replies

•Created by Dimava on 10/29/2024 in #questions

Compiling scope to interfaces

There's just not a good way to do this like I said because you can't dynamically create named references

38 replies

•Created by Dimava on 10/29/2024 in #questions

Compiling scope to interfaces

It's totally opaque and impossible to meaningfully control what gets expanded and how when written to .d.ts files

38 replies

•Created by Dimava on 10/29/2024 in #questions

Compiling scope to interfaces

You may be able to make slight improvements in some cases and if you can submit PRs for them that don't negativly impact type perf/display in other cases that's fine, but 95% of the potential for improvement in these cases is in TS's hands

38 replies

•Created by Dimava on 10/29/2024 in #questions

Compiling scope to interfaces

I've been talking to @Andarist a bit about this and he came up with a very clever stratgy to force standalone infrnce to expand:

const t = type({
    foo: "string"
})

const inferred = t.infer

export type T = typeof inferred

const t = type({
    foo: "string"
})

const inferred = t.infer

export type T = typeof inferred

With this pattern, the standalone exported type can be used even if a reference to arktype isn't resolvable

38 replies

•Created by Dimava on 10/29/2024 in #questions

Compiling scope to interfaces

This is really something that would have to be improved in TypeScript for the most part there's nothing I can do

38 replies

•Created by Dimava on 10/29/2024 in #questions

Compiling scope to interfaces

My "e" is very stick today

38 replies

•Created by Dimava on 10/29/2024 in #questions

Compiling scope to interfaces

There are some tricks you can use for unscoped typs

38 replies

•Created by Dimava on 10/29/2024 in #questions

Compiling scope to interfaces

I think a build tool would be nice for sure. It's just not something TS really gives any ability to control directly (dynamically creating named references)

38 replies

•Created by Dimava on 10/29/2024 in #questions

Compiling scope to interfaces

Sounds like a huge pain. Basically duplicate all the types with the named references or create a build tool to do it

38 replies

•Created by JesusTheHun on 10/29/2024 in #questions

Union of generics

.onUndeclaredKey

23 replies