Repository navigation
Cannot be used to index type in 3.9 (worked in 3.8) #38740
Description
TypeScript Version: 3.9.3
Search Terms:
cannot be used to index type
Code
2536
// A *self-contained* demonstration of the problem follows...// works in 3.8, fails in 3.9
// Is this a bug in 3.9?
// Nexus (nexusjs.org) depended on this functionality
type Get1<
A extends any,
B extends any,
C extends 'filtering' | 'ordering'
> = A extends keyof Stuff
? B extends keyof Stuff[A]
? Stuff[A][B][C] // error here
: never
: never;
interface Stuff {
// [k:string]: any // <-- Putting this here fixes Get1 in TS 3.9
Blog: {
// [k:string]: any // <-- Putting this here fixes Get1 in TS 3.9
posts: {
filtering: 'a',
ordering: 'b'
}
}
}Expected behavior:
TS 3.9 supports the same type logic as in 3.8 (see playground repro)
Actual behavior:
Breaks in 3.9 (our context: graphql-nexus/nexus#859)
Playground Link:
Activity
ahejlsberg commentedon May 23, 2020
The immediate cause of this is #29571. Previously, a type parameter declared with
extends anywas treated as justany, which effectively turned off type checking. For example, you could changeStuff[A][B][C]toStuff[A][42]['elephant']in your example with no error!We now treat
extends anythe same as having no constraint, meaning that things actually get checked. And, in your exampleAmight not include'Blog'andBmight not include'posts', so there is no guarantee that'filtering' | 'ordering'is a valid key forStuff[A][B]. You need to include another check to make it work:jasonkuhrt commentedon May 23, 2020
Ahh thanks Anders Hejlsberg (@ahejlsberg) I thought I tried that 🤦.
I also mistakenly thought that TS would statically analyze that
Stuffonly hadfilteringandordering. I guess though the only way for that to happen would be havingStuffcome through as a constrained generic.There's probably an obvious reason TS must/does behave this way, but I don't see it.
Anyways, getting off-topic here.
Thanks again Anders Hejlsberg (@ahejlsberg)!