Common Generic Type Mistakes in TypeScript

Generics are a powerful TypeScript feature, but they are also easy to misuse. The most common TypeScript generic mistakes come from reaching for generics when a simpler solution exists, or from misunderstanding what type parameters can and cannot do at runtime. Here are the mistakes to watch for.

Adding a Type Parameter When You Do Not Need One

The most frequent mistake is adding a type parameter to a function that only works with one concrete type. Here is an example where T serves no purpose:

typescript

function greet<T>(name: string): string {
  return `Hello, ${name}`;
}

T appears in the angle brackets but nowhere in the function signature. The parameter name is always a string, and the return is always a string, so there is no relationship between T and anything else.

The fix is simple: remove the type parameter and write the function with concrete types instead.

The same applies when a union is clearer than a generic:

typescript

function logValue(value: string | number): void {
  console.log(value);
}

A generic version with a constraint would work, but it adds complexity without benefit. The reader immediately sees which types are accepted with a union.

Use generics when the return type depends on the input type, or when multiple parameters share a type that the caller chooses. If you are not sure whether you need a generic, start with a concrete type or union and only upgrade to generics when the need becomes clear.

Trying to Check a Type Parameter at Runtime

Type parameters are a compile-time concept. They do not exist in the emitted JavaScript:

typescript

function createArray<T>(value: T, count: number): T[] {
  if (typeof T === "string") {
    return Array(count).fill(value);
  }
  return Array(count).fill(value);
}

This does not even compile, because T is a compile-time placeholder with no runtime value to check. TypeScript rejects the comparison itself:

text

'T' only refers to a type, but is being used as a value here.

If you need runtime type information, pass it as a separate argument or use a discriminated union instead of a generic.

This is the same reason you cannot use instanceof with a type parameter. Both typeof and instanceof operate on runtime values, not compile-time types. For runtime validation patterns, see runtime validation in TypeScript.

Forgetting to Add a Constraint When You Need One

Without a constraint, a type parameter can be anything. You cannot access properties that only exist on specific types:

typescript

function getLength<T>(value: T): number {
  return value.length;
}

This produces a compiler error because not every type has a length property. The fix is to add a constraint that requires the property:

typescript

function getLength<T extends { length: number }>(value: T): number {
  return value.length;
}

Now TypeScript knows the property exists, and callers must pass a value that satisfies the constraint. For the full explanation, see generic constraints in TypeScript.

Over-Constraining a Type Parameter

The opposite mistake is making the constraint so narrow that only one type can satisfy it:

typescript

function process<T extends string>(value: T): T {
  return value.toUpperCase();
}

If T can only be string, just write string. A constraint this narrow defeats the purpose of generics. The constraint should represent a meaningful set of types that share a capability, like "has a length property" or "has a name field."

Nesting Generics Too Deeply

Complex nested generics make code hard to read and debug:

typescript

function transform<T, U extends Record<keyof T, V>, V>(
  input: T,
  mapping: U
): { [K in keyof T]: U[K] } {
  return mapping;
}

Three type parameters with interdependent constraints in one line are hard to parse. Break complex generics into named intermediate types:

typescript

type MappingFor<T, V> = Record<keyof T, V>;
 
function transform<T, V>(
  input: T,
  mapping: MappingFor<T, V>
): MappingFor<T, V> {
  return mapping;
}

The named type makes the intent clearer, and the function signature is easier to scan. If a generic type expression takes more than a line to read, extract it into a type alias.

Not Providing a Default When One Type Is Dominant

When one type argument is used far more often than others, provide a default:

typescript

interface Container<T = string> {
  value: T;
}

Now callers can write Container without angle brackets for the common case, and still override when needed. Without the default, every use site must supply the type argument even when it is obvious. For more on this, see default generic type parameters.

Ignoring Inference and Writing Explicit Type Arguments Everywhere

TypeScript infers type arguments from the values you pass. Writing them explicitly everywhere adds noise without providing any additional safety:

typescript

// Unnecessary: TypeScript already knows T is string
const result = identity<string>("hello");
 
// Cleaner: let inference do the work
const same = identity("hello");

Only write type arguments explicitly when inference fails or when you need to override the inferred type. In most cases, letting TypeScript do the work keeps your code cleaner and less repetitive.