Lesson 35 of 80

const Type Parameters

Q: What problem do const type parameters solve that plain generics combined with as const at the call site don't already solve?

A strong answer covers: Shifts the responsibility for literal-type narrowing from every caller (who has to remember as const) to the function signature itself; Every call gets the narrowest inferred literal type automatically, with no risk of a caller forgetting as const; Still purely a type-level effect — no change to runtime behavior of the passed value; Correctly places this as a TypeScript 5.0+ feature.

as const narrows a literal at the call site — but only if the caller remembers to write it. const on a type parameter moves that narrowing into the function signature itself, guaranteed for every call.

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on const Type Parameters

What interviewers actually ask about this, and what a strong answer has to cover.

What problem do const type parameters solve that plain generics combined with as const at the call site don't already solve?

A strong answer covers

Shifts the responsibility for literal-type narrowing from every caller (who has to remember as const) to the function signature itself
Every call gets the narrowest inferred literal type automatically, with no risk of a caller forgetting as const
Still purely a type-level effect — no change to runtime behavior of the passed value
Correctly places this as a TypeScript 5.0+ feature

Likely follow-ups

If a caller explicitly widens a value before passing it in — say, annotates a variable as string[] before calling the function — does const on the type parameter still narrow it?
How is <const T extends readonly unknown[]> different from plain <T extends readonly unknown[]> in terms of what's actually being constrained versus what's being narrowed?
Would you add const to every generic type parameter in a utility library by default, or only in specific cases — and what would guide that decision?

Practice these with the AI interviewer →

The plain-language idea

The type-inference lesson in this track covers as const: a value like ["loading", "success", "error"] widens to string[] by default, and as const locks it down to the exact literal tuple instead. That works — but it depends on every caller remembering to add as const at every call site. Forget it once, and the narrowing silently disappears for that call.

TypeScript 5.0 added a const modifier for type parameters — <const T> — that moves this responsibility from the caller to the function's own signature. Writing <const T> tells the compiler "always infer the narrowest literal type for T at this call, as if the caller had written as const," without the caller ever needing to write it.

See it in a real thing: comparing plain and const generics

function tuple<T extends readonly unknown[]>(...items: T): T {
  return items;
}

const a = tuple("a", "b");
//    ^ inferred as string[] — widened, exactly like an ordinary array literal

function constTuple<const T extends readonly unknown[]>(...items: T): T {
  return items;
}

const b = constTuple("a", "b");
//    ^ inferred as readonly ["a", "b"] — the literal tuple, no as const needed at the call site

Both functions have essentially the same body. The only difference is the const modifier on T's declaration — and that single word changes what every future caller gets by default, permanently, without them doing anything differently.

What people usually miss

Watch out

const type parameters don't make the underlying value more immutable at runtime. Exactly like as const itself, this is a purely type-level narrowing — the array or object passed in is the same plain JavaScript value either way; only TypeScript's inferred type gets more precise.
It shifts responsibility from caller to API author. If you're writing a generic function that benefits from literal-type inference, add const to your own type parameter instead of relying on every consumer of your function to remember as const themselves.
It composes normally with extends constraints. <const T extends string[]> still enforces the constraint — const narrows within whatever the constraint allows, it doesn't loosen or remove the constraint itself.
This is a TypeScript 5.0+ feature. It won't exist on a project pinned to an older compiler version — worth checking the actual installed TypeScript version before relying on it in a shared library's public API, especially one meant to support a range of consumer versions.

Why this matters in interviews

This is a direct extension of the as const idea covered in the type inference lesson elsewhere in this track — being able to explain const type parameters as "moving as const's effect from the call site into the function signature" shows you understand why as const exists in the first place, not just its syntax.