Make IResolvers compatible with IResolvers from graphql-tools

[schickling]

[juicycleff]

Looking into this atm

[brikou]

@schickling upgrading to graphql-tools v4 should solve it, see ardatan/graphql-tools#932

[divyenduz]

@juicycleff : Do you still want to take a stab at this one? 😉

[koenpunt]

Duplicate of #15

[jplew]

@schickling upgrading to graphql-tools v4 should solve it, see apollographql/graphql-tools#932

this does not solve the problem for me. I've got graphql-tools 4.0.3 in my node_modules.

Hacky workaround, for anyone who can't wait until this gets resolved, is to cast resolvers to type any:

Editing the resolver type in graphqlgen.ts will also work, but not recommended since your graphqlgen.ts will be overwritten the next time you run the tool:

[alexedev]

Any update on this?

[maticzav]

@schickling @jasonkuhrt @timsuchanek

[jasonkuhrt]

The problem is a fundamental mismatch between assumptions made by graphqlgen vs Apollo server. Neither is wrong or put another way both are wrong from either one’s point of view.

Apollo has used an index signature on their resolvers type which is not type safe. It allows any invalid prop to be added to resolvers. It makes sense for Apollo server because there is little type safety in its resolvers to begin with including no statically known information about the resolvers object props.

The any-cast is a cheap workaround. I believe this is less evil than introducing index type into graphqlgen. Even semantically it’s rubberish. Resolvers object is not a black box index!

We may be able to use interface declaration merging to have graphqlgen update the Apollo server options type. Ideal because it would require zero compromise from either tool (except for maintenance burden for us).