Graphql-code-generator: typescript-operations generates invalid TS when using interface without type implementation

[SimonSimCity]

Describe the bug

If some definitions in the graphql schema are written as interface without a type implementing it, the @graphql-codegen/typescript-operations package seems to ignore them. The types generated by @graphql-codegen/typescript look fine.

The produced code looks like:

export type ProjectCreateManyMutation = (
  { __typename?: 'Mutation' }
  & { projectCreateMany?: Maybe<(
    { __typename?: 'CreateManyProjectPayload' }
    & { error?: Maybe<> }
  )> }
);

To Reproduce
Steps to reproduce the behavior:

https://codesandbox.io/s/strange-moser-h8gfc?file=/types.ts:708-864

1. My GraphQL schema:

type Query {
    projects: ProjectsPayload
}

input CreateManyProjectInput {
  name: String
}

type ProjectsPayload {
  error: ErrorInterface
}

interface ErrorInterface {
  message: String
}

1. My GraphQL operations:

query project {
    projects {
        error { message }
    }
}

1. My codegen.yml config file:

schema: schema.graphql
documents: document.graphql
generates:
  types.ts:
    plugins:
      - typescript
      - typescript-operations

Expected behavior

The query, generated by @graphql-codegen/typescript-operations, which currently looks like:

export type ProjectQuery = (
  { __typename?: 'Query' }
  & { projects?: Maybe<(
    { __typename?: 'ProjectsPayload' }
    & { error?: Maybe<> }
  )> }
);

Should be generated as valid code. I'd expect something like the following code, which I generated after defining the ErrorInterface using the keyword type instead of the keyword interface:

export type ProjectQuery = (
  { __typename?: 'Query' }
  & { projects?: Maybe<(
    { __typename?: 'ProjectsPayload' }
    & { error?: Maybe<(
      { __typename?: 'ErrorInterface' }
      & Pick<ErrorInterface, 'message'>
    )> }
  )> }
);

Environment:

• OS: MacOS 10.15.6
• @graphql-codegen/add: 1.17.0
• @graphql-codegen/cli: 1.17.0
• @graphql-codegen/typescript: 1.17.0
• @graphql-codegen/typescript-operations: 1.17.0
• NodeJS: v12.18.4

Additional context

If you can help me configuring graphql-compose to return types here would be a work-around which would help me, if you know it by heart - but otherwise, the schema seems to be valid, so the generator should be able to use it.

EDIT:
Discovered that it happens on queries and mutations. Rewrote the example to be a bit smaller in code-size.

EDIT2:
Found out it only happens if there is no type defined implementing the interface - updated my code. I wonder whether this actually is a valid definition ...

[SimonSimCity]

I took a deep look at the server side implementation generating the graphql schema. Comparing the tutorial it with my implementation I found out that I use a new instance of SchemaComposer instead of the instance schemaComposer provided by the package graphql-compose. This was the root cause that the types, implementing the interface ErrorInterface, were not included in my graphql schema. After updating our graphql-server to provide the types implementing the interface ErrorInterface I do not have any rush about fixing this.

Another topic is, if a schema like the one I provided here is considered valid at all ... If no, we can close this. If it is valid, we should find a way to deal with it.

[dotansimha]

Thank you for reporting it @SimonSimCity !
I'm not sure it's really something we can fully resolve here, mainly because we depend on types to exists (because all GraphQL server will always return type eventually, and typescript-operations depends on that assumption).
We do need to have better result here, other than a syntax error, I think I will add unknown type here in this case, to avoid syntax errors. I'll check :)

[dotansimha]

Fixed in: https://github.com/dotansimha/graphql-code-generator/pull/5429
It will now use never instead of syntax error, it will also let you know in case you try to use it - because this will be a runtime error for sure.

[dotansimha]

Fixed in @graphql-codegen/[email protected]. Thank you @SimonSimCity