TypeScript’s new const type parameter syntax lets a function keep literal types intact without forcing callers to sprinkle as const everywhere, cutting the most common source of type-widening bugs.

The widening problem that haunts generic code

When a generic function receives an object literal, the compiler widens any literal property to its broader primitive type. 

function call<T>(arg: T) {}
call({ method: "GET" })   // T is inferred as { method: string }

The literal "GET" collapses to string. Downstream code that depends on the exact value—such as discriminated unions or template-literal extraction—breaks because the type no longer carries the precise literal. Developers have long worked around this by writing { method: "GET" } as const at the call site, which tells the compiler to keep the literal, but that fix lives in the caller’s hands, not the function’s definition.

Const type parameters: a signature-level fix

The new const modifier on a type parameter tells the compiler to infer the narrowest possible type for that generic argument. Declaring a function as function foo<const T>(arg: T) makes T automatically behave as if the caller had written as const.

  • String, number, boolean literals remain their exact values ("GET" instead of string).
  • Arrays become readonly tuples with each element typed precisely.
  • Objects turn into deeply readonly structures, preserving literal types at every nesting level.

Because the constraint lives in the function signature, every caller benefits automatically; forgetting a cast is no longer a path to unsoundness.

Why it beats the classic as const hack

as const is a caller-side solution. It requires every consumer of a generic function to remember to add the assertion. Miss a single call, and the type safety evaporates. The const type parameter moves the responsibility into the API design itself: the function declares “I need the narrowest shape of whatever you pass,” and the compiler enforces it.

That shift matters most for libraries and utilities that expose generic builders, configuration factories, or any API where the literal value of a field drives type logic. The library author can guarantee correct inference without policing downstream code.

Real-world scenarios that profit

  • Configuration builders – environment names ("dev" | "prod") stay literal, enabling discriminated-union checks without extra casts.
  • API route definitions – path strings stay exact, allowing template-literal types to extract parameters ("/users/:id" → \/users/${string}``).
  • State-machine helpers – state identifiers remain fixed literals through method chaining, preventing accidental state mismatches.

In each case the const parameter eliminates a recurring as const boilerplate and reduces the chance of subtle bugs slipping through.

Pairing with the satisfies operator

The satisfies operator validates that a value conforms to a structural type while preserving its original literal information. Using both together gives the best of both worlds: const parameters provide narrow inference, and satisfies ensures the value meets the required shape.

function makeConfig<const C>(cfg: C) {
  // cfg is inferred with exact literals
}
const cfg = {
  env: "staging",
  ports: [8080, 8443],
} satisfies { env: string; ports: number[] };
makeConfig(cfg); // works, literals stay intact

When to keep as const

The const parameter shines when you control the function’s signature. If you’re dealing with third-party functions that lack the modifier, or you need a one-off literal preservation for a local variable, as const remains the right tool. It still serves as the go-to way to freeze a value without altering the called API.

What to watch next

The feature is still fresh, so tooling and community patterns are evolving. Expect updates to IDE support that surface the new syntax in autocomplete and quick-fix suggestions. Keep an eye on library maintainers: many will start migrating public generics to const parameters, which may introduce breaking changes for code that previously relied on explicit as const casts.

Takeaway: By embedding literal preservation directly into a function’s type parameters, TypeScript’s const type parameters remove a common source of widening errors and shift safety from the caller back to the API designer. Use them for any generic entry point you own; reserve as const for local values or external APIs.