Repository navigation
Cannot infer Template Literal Type containing ${number} / ${string} #43060
Description
Bug Report
Cannot infer Template Literal Type containing ${number} / ${string}
🔎 Search Terms
- Template Literal Types number infer
- Template Literal Types string infer
🕗 Version & Regression Information
- This is the behavior of version 4.1 or higher.
⏯ Playground Link
Playground link with relevant code
💻 Code
// ${number} issue
type A<T> = T extends `${infer U}.${infer V}` ? U | V : never
type B = A<`test.1024`>; // This will be "test" | "1024" as expected
type C = A<`test.${number}`>; // Expected "test" | `${number}` or "test" | number but this will be never
type D<T> = T extends `${infer U}.${number}` ? U : never
type E = D<`test.1024`>; // This will be "test" as expected
type F = D<`test.${number}`>; // Expected "test" but this will be never
// ${string} issue
type G<T> = T extends `${infer U}.${infer V}` ? U | V : never
type H = G<`test.hoge`>; // This will be "test" | "hoge" as expected
type I = G<`test.${string}`>; // Expected "test" | `${string}` or "test" | string but this will be never
type J<T> = T extends `${infer U}.${string}` ? U : never
type K = J<`test.hoge`>; // This will be "test" as expected
type L = J<`test.${string}`>; // Expected "test" but this will be never🙁 Actual behavior
Ctype isnever.Ftype isnever.Itype isnever.Ltype isnever.
🙂 Expected behavior
- Expected
Ctype to be"test" | `${number}`or"test" | number. - Expected
Ftype to be"test". - Expected
Itype to be"test" | `${string}`or"test" | string. - Expected
Ltype to be"test".
Activity
jcalz commentedon Mar 22, 2021
I'm sure this goes without saying, but the issue here is not specific to
${number}, but occurs for all "pattern" template literals (as implemented in #40598) like${string}.[-]Cannot infer Template Literal Type containing `${number}`[/-][+]Cannot infer Template Literal Type containing `${number}` / `${string}`[/+]siefkenj commentedon Mar 23, 2021
I just came across this issue when trying to type a REST API. I made a type using templates that could successfully determine the appropriate return type of
get("/sessions/43/posts"), however, my API is most commonly called asget(`/sessions/${sessionId}/posts` as const), which TypeScript failed to recognize.For my purposes, I would be happy if there were some way to tell TypeScript to interpret a template string as a string literal. E.g.,
`abc${x}` === "abc${x}".Some confusion I have with the current implementation is that type type of a
consttemplate seems to be inaccessible.When doing
ywill match against"4.5abc". However, inwill not match against anything more specific than
string(correct me if I'm wrong...), and yet TypeScript will show the type as`${number}abc`.Perhaps tagged-template syntax could be used to specify a template as abstract or weakly inferred?
For example
I'm not sure if these rules would be consistent, but the basic idea would be to not expand
consttypes to strings and allowweaktemplate types to match substitutions directly.