Interface types do not list their parent interface types

[gabrielschulhof]

Which packages are impacted by your issue?

@graphql-codegen/visitor-plugin-common

Describe the bug

When generating code for an interface, its parent interfaces are not listed. e.g:

interface TopLevel {
  topLevelField: Boolean
}

interface MidLevel implements TopLevel {
  topLevelField: Boolean
  midLevelField: Int
}

type BottomLevel implements MidLevel & TopLevel {
  topLevelField: Boolean
  midLevelField: Int
  bottomLevelField: String
}

will result in

type TopLevel = {
  topLevelField: boolean
}

type MidLevel = /* MISSING TopLevel & */ {
  topLevelField: boolean
  midlEvelField: number
}

type BottomLevel = MidLevel & TopLevel & {
  bottomLevelField: String
}

with missing notation shown.

Your Example Website or App

gabrielschulhof/graphql-code-generator

Steps to Reproduce the Bug or Issue

1. Generate TS code from the schema shown in the description.

Expected behavior

The MISSING portion shown in the description is not missing.

Screenshots or Videos

No response

Platform

All platforms

Codegen Config File

import type { CodegenConfig } from '@graphql-codegen/cli'

const config: CodegenConfig = {
overwrite: true,
schema: './data/schema.graphql',
generates: {
'src/types.ts': {
plugins: [
'typescript'
]
}
}
}
export default config

Additional context

No response

[eddeee888]

I'm curious why it needs that @gabrielschulhof ?
Isn't the type correct already?

type MidLevel = {
  topLevelField: boolean // <--- from TopLevel
  midlEvelField: number
}

[gabrielschulhof]

@eddeee888 yes, but the chaining is not captured, whereas it is captured in the case of concrete types -- which is what the useImplementingTypes flag prevents.

[eddeee888]

Hi @gabrielschulhof , I wonder why chaining needs to be captured ?
The typescript interface should be enough.

Linking this to #10522, I feel you might be using this for client use case? If not, please let me know you use case and codegen config and I would be able to advise further

[gabrielschulhof]

@eddeee888 the two PRs are indeed linked. Whenever we make a change to our graph schema, we publish a corresponding package generated with @graphql-codegen. On the client side, we have an in-house client library that makes the requests and types the outputs using the published package. The client library itself is built upon an in-house wrapper around native fetch. Some of our codebase uses our fetch wrapper and the library of generated types directly. The calls to graphql could be coming from the browser or from a server that's doing SSR.

My first reaction is that we cannot directly use the libraries listed at https://the-guild.dev/graphql/codegen/plugins/presets/preset-client because it would require us to overhaul much of our code base, pointing our fetch calls to one of those libraries instead, however, I haven't looked into the client-preset plugin much.

This is our config for type generation:

import type { CodegenConfig } from '@graphql-codegen/cli'

const config: CodegenConfig = {
  overwrite: true,
  schema: './data/schema.graphql',
  hooks: {
    afterOneFileWrite: [
      'prettier --write'
    ]
  },
  generates: {
    'src/types.ts': {
      plugins: [
        {
          add: {
            content: `

export type GraphApiResponse<K extends string, T> = {
  data: { [k in K]: T }
  errors?: Error[]
}

export type GenericDate = string | number | Date
`
          }
        },
        'typescript'
      ]
    }
  }
}
export default config

[gabrielschulhof]

... and thus,

If your stack is not listed above, please refer to our framework/language specific plugins in the left navigation.

caught my eye 🙂

[eddeee888]

Gotcha, thanks for explaining your use case!

For client usage, we recommend using both typescript-operations together with typescript for now to generate correct operation types. e.g.

import type { CodegenConfig } from '@graphql-codegen/cli'

const config: CodegenConfig = {
  overwrite: true,
  schema: './data/schema.graphql',
  documents: './documents/*.graphql', // <--- point to your documents
  hooks: {
    afterOneFileWrite: [
      'prettier --write'
    ]
  },
  generates: {
    'src/types.ts': {
      plugins: [
        {
          add: {
            content: `

export type GraphApiResponse<K extends string, T> = {
  data: { [k in K]: T }
  errors?: Error[]
}

export type GenericDate = string | number | Date
`
          }
        },
        'typescript',
        'typescript-operations' // <--- this will generate correct fields and `__typename` for your documents
      ]
    }
  }
}
export default config

It should handle all the issues you mention, and will be the target for new features.

Note: We are in the process of decoupling these two plugins, so in the future, you'd only need typescript-operations. Reference RFC

---

With that said, I'm not sure how your current process works, so I'm keen to learn more to advise a config that suits your purpose

[gabrielschulhof]

Aaah, we don't have a collection of documents. For the front end, which is in React, we assemble the documents from fragments at runtime, each of which is provided by a component. It'll take quite an effort on our part to move to a list of static documents from where we are now. We could potentially make the documents maximal and use @include/@skip directives to indicate which parts of a document we're interested in. That might allow us to make our documents static.

The only real abstraction we have on the client side is our client library, which is basically a collection of bespoke wrappers around queries and mutations, and which types the responses as they come in, also in a bespoke fashion. To do such typing, it relies on an NPM package of TS types generated using the typescript plugin and published to our registry.

I guess, if providing documents is what it takes to coax it into producing proper types, then maybe I can provide a set of dummy documents and see if that gets me the types in the shape I need them to be in.

[gabrielschulhof]

I created a minimal repo with the schema from #10522 and added both typescript and typescript-operations. I see how typescript-operations unions the possibilities:

export type AbcQuery = { __typename?: 'Query', get_shapes: Array<
    | { __typename?: 'Oval', major_length?: number | null, minor_length?: number | null, color?: { __typename?: 'Color', r?: number | null, g?: number | null, b?: number | null } | null, f1?: { __typename?: 'Point', x?: number | null, y?: number | null } | null, f2?: { __typename?: 'Point', x?: number | null, y?: number | null } | null }
    | { __typename?: 'Triangle', color?: { __typename?: 'Color', r?: number | null, g?: number | null, b?: number | null } | null, p1?: { __typename?: 'Point', x?: number | null, y?: number | null } | null, p2?: { __typename?: 'Point', x?: number | null, y?: number | null } | null, p3?: { __typename?: 'Point', x?: number | null, y?: number | null } | null }
  > };

This is indeed equivalent to __typename?: 'Triangle' | 'Oval' for the given query, even though the declared types still don't have the union:

export type Shape = {
  color?: Maybe<Color>;
};

So, I guess the blocker for us is that solving the problem of having __typename on the client side in a query that is supposed to be polymorphic by processing our documents with typescript-operations is just too wide a scope for us at present.