[typescript-resolvers] Excess properties allowed in resolver return types

[productdevbook]

Problem

TypeScript resolvers don't catch excess properties, allowing invalid data to pass type checking:

// This compiles without errors ❌
const resolvers: Resolvers = {
  Query: {
    user: () => ({
      id: '1',
      name: 'John',
      email: 'john@example.com',
      invalidField: 'should error but doesnt' // No TypeScript error
    })
  }
}

Root Cause

Current ResolverFn uses structural typing:

export type ResolverFn<TResult, ...> = (...) => Promise<TResult> | TResult;

TResult allows excess properties due to TypeScript's structural typing.

Proposed Solution

Add strictResolverReturnTypes config option:

# codegen.yml
config:
  strictResolverReturnTypes: true

Generate exact types:

type Exact<T> = { [K in keyof T]: T[K] } & Record<string, never>;
export type ResolverFn<TResult, ...> = (...) => Promise<Exact<TResult>> | Exact<TResult>;

Expected Result

const resolvers: Resolvers = {
  Query: {
    user: () => ({
      id: '1',
      name: 'John', 
      email: 'john@example.com',
      invalidField: 'now errors' // ✅ TypeScript error
    })
  }
}

Backward compatible, opt-in feature for better type safety.

• typescript-resolvers Add type checking when a mapped type in ResolversParentTypes does not match the corresponding schema type dotansimha/graphql-code-generator#9444

[eddeee888]

Hi @productdevbook , I'm from the GraphQL Codegen team 👋

I'm curious if passing excess properties are causing runtime issues or is this just a type preference?

[productdevbook]

Hi @eddeee888! Thanks for reaching out 👋

It's primarily a type safety preference, but it can lead to runtime issues in certain scenarios:

1. Performance: Excess properties get serialized and sent over the network unnecessarily
2. Security: Accidentally exposing sensitive fields that shouldn't be part of the GraphQL schema
3. Data consistency: Makes it harder to catch bugs where resolvers return incorrect data structures
4. Developer experience: Without strict typing, developers might assume excess properties are part of the actual GraphQL response

The main goal is to catch these issues at compile-time rather than discovering them in production. Making it an opt-in strictResolverReturnTypes config would be perfect for teams that want stricter type safety without breaking existing codebases.

Would be happy to help test this feature once implemented!

[eddeee888]

Thanks for the explanation @productdevbook !

1. Performance: Excess properties get serialized and sent over the network unnecessarily

AFAIK, GraphQL does not send extra data over the network if (1) it doesn't exist in the schema and (2) not queried.
(If I misunderstood your statement, please let me know.)

2. Security: Accidentally exposing sensitive fields that shouldn't be part of the GraphQL schema

Generally, I recommend only to add fields you intend to make public to the GraphQL schema to avoid this issue.

3. Data consistency: Makes it harder to catch bugs where resolvers return incorrect data structures

Do you have an example for this? 🙂

4. Developer experience: Without strict typing, developers might assume excess properties are part of the actual GraphQL response

I feel GraphQL users generally know properties may (or may not) go from the resolver to the response.
In fact, any property (not just excess properties) returned by resolvers are not guaranteed to be in the response with the same value or type.

If I understood something, please let me know! 🙏
(If so, I may need examples to understand it further)

[productdevbook]

You're right that GraphQL doesn't send extra fields to clients, but the real issue is about code cleanliness and maintainability during development.

The Problem: Code Becomes Messy Over Time

Without strict return types, developers must constantly cross-reference the GraphQL schema to know what's actually being used:

// Current situation - no TypeScript errors
export const userResolver = {
  Query: {
    getUser: async (_, { id }) => {
      const user = await db.getUser(id);
      return {
        id: user.id,
        name: user.name,
        email: user.email,
        role: user.role,          // Is this field still in schema?
        department: user.dept,     // What about this one?
        lastLogin: user.lastLogin, // And this?
        isActive: user.active,     // Need to check schema...
      };
    }
  }
};

Why This Matters

1. Cognitive Load: Every time you work on a resolver, you need to:

   • Open the GraphQL schema file
   • Check which fields are actually defined
   • Manually verify your return matches the schema

2. Dead Code Accumulation: After months of development:

   return {
     id: user.id,
     name: user.name,
     email: user.email,
     // These might all be removed from schema but still here:
     role: user.role,
     department: user.dept,
     oldFieldV1: user.something,
     tempFlag: user.flag,
     // Which fields are actually used? 🤷
   };

3. Code Reviews Become Harder: Reviewers can't tell if a field is intentionally returned or just forgotten dead code without checking the schema separately.

With strictResolverReturnTypes, TypeScript would immediately flag any field not in the schema, keeping the code clean and self-documenting. You'd know exactly what fields are valid just by looking at the resolver - no need to constantly jump between files.

This is especially valuable in teams where not everyone knows the entire schema by heart. The code itself becomes the documentation.