Template literal types: compute, expand, and parse string types

Interpolation and the union cross product

Why bother generating string types instead of just listing them? Because the set of valid strings often grows with your data model — a locale like "en-US" should be derivable from Lang and Region types you already maintain, so adding "fr" to Lang automatically produces "fr-US" and "fr-GB" without touching the locale type.

A template literal type looks like a JS template string but operates on types. Interpolating a single literal is unsurprising; interpolating a union expands into every combination — the full cross product:

type Greeting = `Hello, ${string}!`;     // any "Hello, ...!" string
type Hi = Greeting & "Hello, Sam!";      // ^? "Hello, Sam!"  (it's a member)

type Lang = "en" | "ru";
type Region = "US" | "GB";
type Locale = `${Lang}-${Region}`;
// ^? "en-US" | "en-GB" | "ru-US" | "ru-GB"   — 2 x 2 = 4 members

Each interpolation slot multiplies the member count. Two 2-member unions give 4; add a third 3-member union and you get 12; the growth is multiplicative. This is the headline pitfall: a template over several big unions can generate thousands of members and slow or stall the checker.

Intrinsic case manipulators

Four built-in (compiler-implemented) string types transform case, with no library definition you could write yourself:

type U = Uppercase<"hello">;     // ^? "HELLO"
type L = Lowercase<"HELLO">;     // ^? "hello"
type C = Capitalize<"hello">;    // ^? "Hello"
type N = Uncapitalize<"Hello">;  // ^? "hello"

These are the pieces behind key renaming (get${Capitalize<K>} from last lesson) and typed event-name builders.

Parsing with infer inside a template pattern

The real power: put infer inside a template literal in a conditional’s extends clause to pull substrings out. To extract a route parameter:

type RouteParam<S extends string> =
  S extends `${string}:${infer Param}/${string}`
    ? Param
    : S extends `${string}:${infer Param}`
      ? Param
      : never;

type P1 = RouteParam<"/users/:id">;        // ^? "id"
type P2 = RouteParam<"/users/:id/posts">;  // ^? "id"

For multiple params you recurse, collecting each into a union — the building block for fully typed routers. Splitting a delimited string is the same idea:

type Split<S extends string, D extends string> =
  S extends `${infer Head}${D}${infer Tail}`
    ? [Head, ...Split<Tail, D>]
    : [S];

type Parts = Split<"a-b-c", "-">;
// ^? ["a", "b", "c"]

Inference is non-greedy at the first delimiter

When a pattern has ${infer Head}<delimiter>${infer Tail}, Head matches as little as possible — up to the first occurrence of the delimiter, not the last:

type FirstSeg<S extends string> =
  S extends `${infer Head}-${infer Tail}` ? [Head, Tail] : [S];

type R = FirstSeg<"a-b-c">;
// ^? ["a", "b-c"]   — Head stops at the FIRST '-', Tail takes the rest

So Split above peels one segment per recursion from the left. If you assumed Head would greedily swallow "a-b", the resolved type would surprise you — the non-greedy, leftmost-delimiter rule is what makes left-to-right recursive parsing work.

The cost side: a parser in the type system is a parser you can’t debug

Template literal types are the point where TypeScript stops being a type-checker and starts being a string-processing language — and that is exactly where to be most disciplined. The cross-product cost is real and steep: a single template that interpolates four segments where each ranges over the alphabet is 26⁴ ≈ 457,000 members, far past the 100,000-member cap, so tsc either errors with Expression produces a union type that is too complex to represent or, with recursion in the mix, exhausts the heap and OOMs (Node’s default 2–4 GB) outright. Even short of the cap, a recursive Split/parser over a long string is non-tail recursion that hits the instantiation-depth wall (50 deep) and falls back to string, silently discarding the precision you wrote the type for.

The senior breakpoint: a parsed template type buys end-to-end string safety — the :id in a route is checked against the handler’s req.params with no runtime cost and no duplicated declaration. That is worth a lot for a library boundary where the string format is the API (a router, a typed i18n key, an SQL-ish DSL). It is rarely worth it inside application code: a 40-line recursive template parser is unreadable to the next engineer, produces error messages that point at the type machinery rather than their mistake, and taxes every editor keystroke. When you find yourself parsing a non-trivial grammar at the type level, that is the signal to move it to a build/codegen step — generate the route map, the i18n key union, or the query types as flat named types from the source of truth. The generated type Routes = "/users/:id" | ... is greppable, hover-clean, and compiles instantly; the recursive template that derives it is a parser no debugger can step through. Reach for templates when the string itself is the contract; reach for codegen when the string needs parsing.