sinclairzx81
commented
1 year ago @tsujp Hi,
Um, I don't think this is a TypeBox bug, but this usage would be running up against the extents of the TS compiler and inference capabilities. I had a quick hack around and largely ran into the same issues. I've tried to make the supporting types a bit more obvious here (you can test them individually), but the main issue seems to be TypeScript losing track of the specific TSchema when evaluating the type with this usage pattern.
import { Type, Static, Evaluate, UnionToTuple, TSchema, TProperties } from '@sinclair/typebox'
// ------------------------------------------------------------------
// HttpMethods
// ------------------------------------------------------------------
export type ToLower<T extends readonly string[]> = { [K in keyof T]: Lowercase<T[K]> }
export type HttpMethods = typeof methodsLower[number]
const methodsUpper = ['GET', 'POST', 'PUT', 'DELETE'] as const
const methodsLower = methodsUpper.map((v) => v.toLowerCase()) as unknown as ToLower<
typeof methodsUpper
>
// ------------------------------------------------------------------
// Parse
// ------------------------------------------------------------------
export type ParseComponents<P extends string> = P extends `/${infer Path}`
? Path extends `${infer Segment}/${infer Rest}`
? Segment | ParseComponents<`/${Rest}`>
: Path
: never
export type ParseSlugs<P extends string> = P extends `{${infer Slug}}` ? Slug : never
export type ParsePropertyUnion<T extends string> = ParseSlugs<ParseComponents<T>>
export type ParsePropertyNames<T extends string> = UnionToTuple<ParsePropertyUnion<T>>
export type ParseObjectProperties<T extends string[]> =
T extends [infer L extends string, ...infer R extends string[]]
? { [_ in L] : TSchema } & ParseObjectProperties<R>
: {}
// ------------------------------------------------------------------
// ValidationObject
// ------------------------------------------------------------------
export type ParseValidationObject<T extends string, S = ParsePropertyNames<T>> = S extends string[]
? Evaluate<ParseObjectProperties<S>>
: {}
export type StaticValidationObject<T> = T extends TProperties ? {
[K in keyof T]: Static<T[K]>
} : never
// ------------------------------------------------------------------
// TypedRouter
// ------------------------------------------------------------------
export type TypedRouter = {
[M in HttpMethods]: <
P extends string,
T = ParseValidationObject<P>
>(
path: P,
validation: T, // evaluation of T (via Pick or other) will have TS lose track of generic types.
handler: (ctx: StaticValidationObject<T>) => Response
) => Response
}
// ------------------------------------------------------------------
// Example
// ------------------------------------------------------------------
declare const foo: TypedRouter
foo.get(
'/foo/{bar}/lorem/{ipsum}/{dolor}',
// Using Type.Object fixes inference but breaks slug-key checking.
{
bar: Type.Integer(),
ipsum: Type.String(),
dolor: Type.Boolean(), // Comment me to receive a type error about missing key `dolor`
// extra: Type.String(), // Uncomment me to receive a type error about additional key `extra`
},
(ctx) => {
ctx.bar // Type is `unknown`, expect `number`.
ctx.ipsum // Type is `unknown`, expect `string`.
ctx.dolor // Type is `unknown`, expect `boolean`.
return new Response('Foo bar')
}
)So, the above does do inference, however the extra property is allowed (which is probably not desirable). Unfortunately, I can't seem to have TS retain the generic TSchema AND ensure additional properties are disallowed. So, not too sure here...however, you can repro TS losing track of generics by forcing TS to evaluate the type (this also prevents disallowed properties, but at a cost of losing inference)
type BreakInfer<T> = T extends infer O ? O : never
// ^ force evaluation here
export type TypedRouter = {
[M in HttpMethods]: <
P extends string,
T = ParseValidationObject<P>
>(
path: P,
validation: BreakInfer<T>, // broken here
handler: (ctx: StaticValidationObject<T>) => Response
) => Response
}I expect there would be a way to implement this (it might just take some refactoring and deep diving into various ways to express this form of mapping), but yeah, I don't think this is specifically related to TypeBox.
Hope this helps S
tsujp
I'm attempting to write a typed router and I'm stuck on what I think is a TypeBox issue or a fundamental quirk of TypeScript. I've spent a few hours trying to solve it myself but cannot figure out where the real error is coming from but I think I've narrowed it down.
The goal is to define a function interface which takes a route path and a schema object where every slug (parameterised route variable) must be in the schema object and both must have no extra keys with respect to each other. I can achieve this but subsequently calling
Staticon the schema object results in said type erasure.Using a proper
Type.Objectas the schema object prevents type erasure but loses the slug and schema object key checking.Here's my best attempt thus far: