loke.dev
Header image for Fixing TypeScript Generic Inference Failures and Unknown Types
typescript web-development compiler zod

Fixing TypeScript Generic Inference Failures and Unknown Types

Stop fighting the compiler. Learn to fix TypeScript generic inference failures, handle unknown fallbacks, and resolve strict mode migration errors effectively.

Published 4 min read

Your generic parameters aren't doing what you think they are. When you hit an error claiming 'unknown' is not assignable to type 'T', you aren't fighting a compiler bug. You're fighting the fact that your generic constraints are invisible to the inference engine.

Most devs treat generics like runtime arguments. They pass them in and pray the compiler figures it out. But the inference engine is lazy by design. When it sees a complex signature, it defaults to the constraint instead of forcing a resolution. Stop trying to write clever polymorphic functions. Pin your types to the structure you actually expect.

The Unknown Trap

I see this pattern in PRs every week:

function processData<T>(input: T): T {
  return input.map(item => item.id);
}

The compiler screams that 'map' doesn't exist on type 'T'. You might reach for a constraint like <T extends { map: any }>. Don't do that. You're lying to the compiler about the shape of your data.

When inference fails, stop over-constraining. Look at the inputs. If the function only cares about an 'id' property, type it that way:

function processData(input: { id: string }[]): string[] {
  return input.map(item => item.id);
}

If you must use a generic, use it to capture the shape, not to define it. The satisfies operator is the right tool to verify an input meets a contract without nuking your type information.

Bridging the Runtime Gap

Static types die the moment a fetch call hits the wire. You spend hours crafting nested interfaces, then the backend adds a nullable field and crashes your frontend. That's Zod schema drift.

If you are still writing manual TypeScript interfaces for API responses, stop. Use Zod to define a schema and derive the types from there.

import { z } from 'zod';

const UserSchema = z.object({
  id: z.string(),
  email: z.string().email(),
});

type User = z.infer<typeof UserSchema>;

By using z.infer, you force the static type to match the runtime validator. If the API changes, the schema changes. If the schema changes, the error pops up in your IDE instantly. You stop playing tag with your backend docs.

Strict Mode Migration Fatigue

TypeScript 6.0 makes strict mode the default. If you are migrating a legacy codebase, you're probably staring at a mountain of red squiggles.

Do not try to fix them all at once. The everything-at-once strategy invites 'any' injections, which kill the value of the migration. Go incremental. Keep strict false in your global config. Enable specific flags one by one. Start with noImplicitAny and strictNullChecks. These two catch the vast majority of logic bugs.

The biggest breaking change in 6.0 is the moduleResolution shift to bundler. If imports fail or your output looks like dist/src instead of dist, check your rootDir. TypeScript 6.0 is pickier about the base directory. Set rootDir to ./src to keep the compiler from hallucinating your structure.

Forcing Safety with NoInfer

Sometimes TypeScript tries to be too smart. It unifies multiple arguments, resulting in aggressive type widening.

If you have a function taking two arguments that must share a type, use the NoInfer utility type. It tells the compiler to quit trying to calculate the type from that specific argument.

function createPair<T>(first: T, second: NoInfer<T>): [T, T] {
  return [first, second];
}

// This will now correctly error if the types don't match
createPair("hello", 123);

NoInfer is your best lever for stopping the compiler from guessing. Use it to enforce relationships between parameters without letting the compiler widen types into a common parent.

When to Stop

Don't force these patterns everywhere. If a function is simple, just write the types out. Generics exist for when the relationship between types actually matters, not for when you're too lazy to define an interface.

If you find yourself nesting generics more than two levels deep, or using conditional types to map over everything, step back. That complexity is hiding a design flaw in your data. Tighten your types at the edges. Define your boundaries at the API and database levels, then let the rest of the app rely on concrete shapes. Stop fighting the compiler and start defining your ground truth.

Resources

- TypeScript Handbook on Generics (typescriptlang.org)
- Deep dive into Zod and Type inference patterns (medium.com)
- Discussion on TypeScript 6.0 compiler option changes (github.com)

Resources