Constraining Generics with extends

Constraining generics is powerful, but there are several traps that catch developers off guard. Let us walk through the most common mistakes so you can avoid them in your own code.

Trap 1: Constraint Too Loose. Using <T extends object> is very broad. The only thing it guarantees is that T is not a primitive. It does not give you access to any specific properties or methods. If you need .length, use <T extends { length: number }> instead. Always use the most specific constraint that captures your requirement:

// Too loose!
function process<T extends object>(data: T) {
  console.log(data.length); // ERROR!
  // object has no .length
}

// Better — specific constraint
function process<T extends { length: number }>(
  data: T
) {
  console.log(data.length); // OK!
}

Trap 2: Constraint vs Type Annotation Confusion. <T extends string> and (item: string) are NOT the same thing. The constraint means T can be string or any subtype of string (like the literal type "hello"). The annotation forces the parameter to be exactly string. With constraints, the caller can pass literal types and the compiler preserves that information. With plain annotations, the type gets widened:

// Constraint: preserves literal types
function logA<T extends string>(val: T): T {
  return val;
}
const a = logA("hello");
// type of a is "hello", not string!

// Annotation: widens to string
function logB(val: string): string {
  return val;
}
const b = logB("hello");
// type of b is just string

Trap 3: Constraint Does Not Give All Methods. If you constrain <T extends { length: number }>, you only get .length. You do NOT get .toUpperCase() or .push() or .slice(). You only get what the constraint explicitly declares. This trips up many developers who expect all of string's or array's methods:

function process<T extends { length: number }>(
  item: T
) {
  console.log(item.length);  // OK
  console.log(item.toUpperCase()); // ERROR!
  console.log(item.push(1)); // ERROR!
  // Only .length is available
}

Trap 4: Over-Constraining. Do not add constraints you do not need. If your function does not use .length, do not add extends { length: number }. Unnecessary constraints make your function less reusable. Other developers will be forced to satisfy a constraint that serves no purpose:

// BAD: constraint you never use
function printItem<T extends { length: number }>(
  item: T
) {
  console.log(item); // .length unused!
}

// GOOD: only constrain what you need
function printItem<T>(item: T) {
  console.log(item);
}

Trap 5: Constraint with any. Writing <T extends any> is the same as unconstrained <T>. It is meaningless but TypeScript does not throw an error. It just adds noise to your code. Do not write it:

// Meaningless — same as <T>
function process<T extends any>(item: T) {
  // T is still unconstrained
}

// Just write this instead
function process<T>(item: T) {
  // Same thing, cleaner
}

Trap 6: Self-Referencing Constraint. <T extends T> is always true and therefore pointless. It looks weird, TypeScript allows it, and it does absolutely nothing. Do not write this — it confuses other developers and adds no value. If you see it in code, it is a bug or a misunderstanding.

Keep these traps in mind and your constrained generics will be clean, useful, and bug-free. The key principle: constrain exactly what you need, nothing more and nothing less!