Repository navigation
On DT, lambda-tester is broken by better alias preservation #51698
Description
lambda-tester is broken by #51152.
Conditional type instantiation seems to proceed differently for an alias when it was constructed without type parameters that are later defaulted:
type Actual = lambdaTester.Verifier<lambdaTester.HandlerResult<Handler>>
type Expected = lambdaTester.Verifier<lambdaTester.HandlerResult<Handler<any, any>>>
// from lambda-tester's index.d.ts:
type HandlerResult<T extends Handler> = T extends Handler<any, infer TResult> ? TResult : never;
type Verifier<S> = S extends HandlerError<Handler>
? (S extends string ? VerifierFn<string>
: S extends Error ? VerifierFn<Error>
: never)
: VerifierFn<S>;
class LambdaTester<T extends Handler> {
// ....
expectSucceed(verifier: Verifier<HandlerResult<T>>): Promise<any>;
// ....
}
// from aws-lambda's index.d.ts:
export type Handler<TEvent = any, TResult = any> = (
event: TEvent,
context: Context,
callback: Callback<TResult>,
) => void | Promise<TResult>;Actual and Expected are both VerifierFn<string> | VerifierFn<Error> | VerifierFn<any> before #51152. Afterwards, Actual is VerifierFn<unknown>.
Activity
weswigham commentedon Dec 5, 2022
Nathan Shively-Sanders (@sandersn) locally I see both
ActualandExpectedasVerifierFn<unknown>, at least onmainnow. It's possible #51762 "fixed" this by ensuring both behave the same again, by ensuring both have analiasTypeArgumentslist. Still, it's definitely weird for it to beVerifierFn<unknown>- it implies something weird with the instantiation ignoring theanytype argument default/passed value and using the constraint instead... I'll keep looking into it.sandersn commentedon Dec 5, 2022
I'll watch https://dev.azure.com/definitelytyped/DefinitelyTyped/_build?definitionId=8&_a=summary to see if lambda-tester passes tomorrow.
weswigham commentedon Dec 5, 2022
Ah, nope, I'm mistaken, my test case was incomplete - the two forms do, in fact, vary - notably, my test was missing an import for
Handler, the result of which makes it behave identically to theVerifierFn<unknown>case, which may help indicate what's going on here.weswigham commentedon Dec 5, 2022
Figured it out - initially thought it was a difference between weather we did alias inference before or not, but while it is related to alias inference, and needing to make alias inference happen here when it wasn't, it turns out we are doing alias inference already, all that changed was the type argument list (specifically, the earlier preserved alias now has an empty argument list, since it relies on default application). So it turns out it's actually an issue to do with not applying defaults to alias type argument lists during inference, and thus skipping inferences caused by type argument list defaults~
Fix looks pretty small. Will have a PR for extended suite checks shortly~