Usage of generated typescript types / general typescript questions

[codepunkt]

I'm using nexus in a typescript-based graphql server and have a few questions in regard to typing this correctly, sorted in order of (subjective) importance:

import { arg, queryType } from 'nexus'
import { Context } from '../Context'

export const Query = queryType({
  definition: t => {
    t.field('getProject', {
      nullable: true,
      type: 'Project',
      args: {
        id: arg({
          type: 'String',
          description: 'Project id',
          nullable: false,
        }),
      },
      async resolve(root: any, args, ctx: Context, info: any): Promise<any> {
        return await ctx.getProject(args.id)
      },
    })
  },
})

1. how can i type the return value of my resolver, e.g. Promise<Project> instead of Promise<any>? Typescript types are auto-generated, but i'm confused about the way to use them (i'd want to use them on both server (resolver return value) and client). Also, based on the docs, i don't understand the typegenConfig and typegenAutoConfig parameters of makeSchema at all - the ghost example doesn't help either. I assume these configuration options have something to do with the usage of the generated typescript types.
2. why does the info parameter of the resolver have no type information?
3. is there a way to get type information on the root parameter?

[tgriesser]

1. how can i type the return value of my resolver, ...

With Nexus the idea is that you shouldn't ever need to annotate types in the resolver as you are doing above. By configuring the makeSchema's typegenAutoConfig you can configure what modules containing your types are imported (e.g. mongoose models, schemats output, just general classes or type files you've written). These types are then properly inferred on the fields based on the name of the type and the name of the field, using type inference/conditional types and global type merging.

The typegenAutoConfig uses a configurable regex matcher get the imports so they are auto-picked up based on the name of the types. You can pass debug: true as an option to the typegenAutoConfig to see a little more about how it's trying to find the associated type names. You can also specify them manually using a backingTypeMap option

typegenConfig is only if you wanted to build/supply your own type matcher that's more advanced than the one provided by the auto-config. The types generated are specific to nexus' use on the inference & merging and aren't really suitable for client re-use right now. I would like to add support for adding this as a config option, since I think having these are helpful and should be simple enough for us to allow, but for right now you might want to use something like graphql-code-generator.

If you want to get the resolver typing, for use elsewhere, for instance if you wanted to move your resolve fn into its own file, we export a FieldResolver helper.

2. No types for the info parameter:

It should be typed? Where are you seeing that it isn't?

3. is there a way to get type information on the root parameter?

Once you have the root types setup with the generator, the root types and return types shouldn't be "any" anymore, they should be correct based on what the field is resolving with. In order to see the types for the root, args, ctx, you can right click on the type and click "go to type definition".

I map this to cmd+' myself. Unfortunately jumping to the field expected return type doesn't work, and i'm not sure there's a good solution here right now, other than looking at the "field types" in the generated types file

[Weakky]

other than looking at the "field types" in the generated types file

One quick suggestion here: I have put the main interface at the top of the file in the generated typings of nexus-prisma to ease navigation across the file. As TS doesn't require types to be defined before being used, it should be fine and make the file clearer