TypeScript GraphQLObjectType and TArgs

The TypeScript definitions currently specify a TArgs generic type on GraphQLObjectType which then flows into GraphQLObjectTypeConfig, GraphQLFieldConfigMap and GraphQLFieldMap.

All field resolver arguments on an object therefore have to have the same base type.

This, to me, is unexpected as each resolve function can have it’s own differing requirements as to what arguments and it makes it awkward to use types arguments as you need to specify something like any when creating the GraphQLObjectType instance. For example:

interface MySource { /* ... */ }
interface MyContext { /* ... */ }

interface MyFieldArgs {
    foo?: number;
    bar: string;
}

interface MyOtherFieldArgs {
    baz: string;
}

const MyType = new GraphQLObjectType<MySource, MyContext, any>({
    fields: {
        myField: {
            args: {
                bar: { type: new GraphQLNonNull(GraphQLString) },
                foo: { type: GraphQLInt },
            },
            resolve: (source, args: MyFieldArgs, context, info) => { /* ... */ },
            type: GraphQLString,
        },
        myOtherField: {
            args: {
                baz: { type: GraphQLString },
            },
            resolve: (source, args: MyOtherFieldArgs, context, info) => { /* ... */ },
            type: GraphQLString,
        },        
    },
    name: "My",
});

I suppose you could stick with the default TArgs type and then use a typescript user-defined type guard. However this is even more awkward and seems unnecessary given that we are specifying the arguments in the GraphQLFieldConfig and can be sure that graphql has already validated and asserted that the arguments match what we expect when it comes to calling the resolve function.

function isMyFieldArgs(o: any): o is MyFieldArgs {
    /* check everything ... */
    return true;
}

{
    // ...
    resolve: (source, args, context, info) => {
        if (!isMyFieldArgs(args)) {
            return undefined;
        }
        /* ... */
    },
}

[williambailey]

Having just gone through the migration to v15 this is still an issue and arguebly worse since #2488.

Now we have GraphQLObjectType<TSource = any, TContext = any> so we can’t specify TArgs as any at the top level and have it propagate to the children which default to TArgs = { [key: string]: any }.

This then leads to the situation where your typescript failes to build when you try to have infered and typed TArgs in your resolvers with errors such as:

Type '{ [argName: string]: any; }' is missing the following properties from type 'MyImageRequestArgs': height, width ts(2322)
definition.d.ts(447, 3): The expected type comes from property 'fields' which is declared here on type 'Readonly<GraphQLObjectTypeConfig<MySourceObject, MyContextValue>>'

MyImageRequestArgs in this instance would look something like

interface MyImageRequestArgs {
    [argName: string]: any;
    height: number;
    width: number;
}

Our workaround at the moment is to patch the GraphQLFieldConfig definition with something like

--- a/node_modules/graphql/type/definition.d.ts
+++ b/node_modules/graphql/type/definition.d.ts
@@ -511,7 +511,7 @@
 export interface GraphQLFieldConfig<
   TSource,
   TContext,
-  TArgs = { [argName: string]: any }
+  TArgs = any
 > {
   description?: Maybe<string>;
   type: GraphQLOutputType;

I will continue to see if there is something else going on that i’m missing but thought i’d give a quick update to the ticket.

[dmastrorillo]

Do we have an update on this? I using version 15.5.0 and still facing the aforementioned issue

Type 'GraphQLFieldResolver<undefined, Context, MutationSignupArgs>' is not assignable to type 'GraphQLFieldResolver<undefined, Context, { [argName: string]: any; }>'. Type '{ [argName: string]: any; }' is missing the following properties from type 'MutationSignupArgs': firstName, lastName, email