Template string index signature type inference inconsistency when assigning directly and via reference

[ornberg]

🔎 Search Terms

"template literal" "computed property keys"

🕗 Version & Regression Information

• This is the behavior in every version I tried (from 4.4.4 up to Nightly)

⏯ Playground Link

https://www.typescriptlang.org/play?declaration=false&ts=5.2.2#code/C4TwDgpgBAKlC8UDeUDaBrCIBcUAGYAThAGYCWAHgPoAkSAzsIWQHYDmAvngLq4sCuAWwBGEQlA4AoAMYB7FoygBDXHEQoKffgBttEqAHoDUAEoR6O4PSisoECpGnAIAEzuFCswpJnzFwhGQoTSgBXQlfBWAoaVVAgKMoAFEHCCdXZRZ3T0IAGihhfmi2MgA3c1D5CB85KKgXOPVgrXCOZWsNFr02xIBhJUZWNhto4FkoYAALaHolQWhQSCgAd2mslzTtJWZ2EfqyYidtEGVtenHiC20rGyyWcbEcoA

💻 Code

type T = { [key: `prefix_${string}`]: number }
const a: T = { x: null } // Results in expected error

const b = { x: null }
const c: T = b // Expected an error, but gives none

const d: T = { x: null } as { x: null } // Casting it to the same type when declaring it directly also results in no error

🙁 Actual behavior

Error declaring a, and no error when declaring c or d.

🙂 Expected behavior

Declaration of c and d to give the same error as when declaring a.

Additional information about the issue

If this is another case of #13948, the lack of errors on property keys makes sense to me. Although I am unsure if #27144 is responsible for the lack of errors on value type or not.

Regardless of whether to expect an error or not, I would assume the declaration of a and c to produce the same result.

[whzx5byb]

{ x: null } is a valid subtype of { [key: `prefix_${string}`]: number }, so it is expected to get no error when declaring c or d. The error you got when declaring a is caused by Excess Property Checks.

[Glaum96]

{ x: null } is a valid subtype of { [key: `prefix_${string}`]: number }, so it is expected to get no error when declaring c or d. The error you got when declaring a is caused by Excess Property Checks.

Why is { x: null } is a valid subtype of { [key: prefix_${string}]: number } ?

[danny-may]

{ x: null } is a valid subtype of { [key: `prefix_${string}`]: number }, so it is expected to get no error when declaring c or d. The error you got when declaring a is caused by Excess Property Checks.

Why is { x: null } is a valid subtype of { [key: prefix_${string}]: number } ?

Because all keys in { x: null } which match prefix_${string} (0 keys) are of type number. x is an excess property which gets ignored because it isnt constrained by T.

The error with const a: T = { x: null } is Object literal may only specify known properties, and 'x' does not exist in type 'T'., but const c: T = b doesnt involve an object literal, so no error.

[fatcerberus]

To clarify on the above point: The index signature doesn’t constrain the set of allowed keys, but only the types of the properties it matches. You may have intended that objects could only contain properties with names starting with prefix_, but that’s not possible to enforce without #12936.

Note that this is much less misleading in TS 5.3 (currently in beta), where the “not assignable” wording is removed from the error message.