In a TypeScript conditional type, what does adding a constraint to an inference variable — as in `infer N extends number` — change compared with a bare `infer N`?

## Two jobs in one piece of syntax A bare `infer N` accepts whatever occupies the slot. Adding `extends` after the name — `infer N extends number` — constrains the candidate, and the compiler uses that constraint in two distinct ways. ## Job one: filtering into the false branch ```ts type IdOf<T> = T extends { id: infer U extends string } ? U : "no-string-id"; type A = IdOf<{ id: "abc" }>; // "abc" type B = IdOf<{ id: number }>; // "no-string-id" ``` When the candidate fails the constraint the whole pattern fails, so the conditional falls to the false branch. Note what does *not* happen: it is not a compile error, and the variable is not silently widened or narrowed to the constraint. It is a match failure, exactly like passing a non-array to an array pattern. The alternative spelling is a nested conditional — infer without a constraint, then test the result. The constrained form is shorter and keeps the intent in one place, which matters when a pattern already has several inference sites. ## Job two: changing what is inferred in a template literal This is the reason the feature was added. Placeholders in template literal types normally yield string literals, because that is what a string is made of: ```ts type Bare<S extends string> = S extends `${infer N}` ? N : never; type C = Bare<"42">; // "42" — a string literal ``` With a numeric constraint the compiler produces a numeric literal instead: ```ts type ToNumber<S extends string> = S extends `${infer N extends number}` ? N : never; type D = ToNumber<"42">; // 42 — a number literal type E = ToNumber<"x">; // never — the constraint failed ``` That single change turns a common chore — recovering a numeric value that arrived encoded in a string type — into one line. `infer B extends boolean` behaves the same way for `"true"` and `"false"`, and `infer K extends string` is used when you want to constrain a captured key to something usable as a property name. ## What it is not It is easy to conflate this with two other constraint mechanisms. A constraint on a *type parameter* — `type F<T extends string> = ...` — restricts what callers may pass and produces an error at the use site when violated. A constraint on an *inference variable* restricts what the pattern will match and produces a silent branch change instead. Same keyword, different consequence, and mixing them up leads people to expect an error where the code simply takes the other branch. It is also not a conversion. `infer N extends number` does not turn a string into a number at runtime, because there is no runtime involved at all: the conditional type is erased, and the numeric literal exists only in the checker's model of the program. If you also need the value at runtime you still have to parse the string in JavaScript; the type-level and value-level work are independent. ## Practical guidance Use the constrained form when a helper only makes sense for a particular kind of candidate, and let the false branch express the fallback — a sentinel literal reads far better in an error message than a bare `never`. Reach for it especially when pulling structured data out of string-shaped types, where recovering a numeric or boolean literal directly saves an entire layer of conversion machinery. This discussion assumes the TypeScript 5.x line and later. The constrained form is not universally available in very old compilers, so it is worth confirming the compiler version before using it in a package that supports a wide range of consumers.