[relay-compiler] not yet implemented: InputObjectTypeExtension

[GalvinGao]

Problem

When using an extend input syntax, the relay compiler panicked and failed to generate. An example schema would be:

input HelloInput {
  name: String
}

extend input HelloInput {
  age: Int
}

type Query {
  hello(input: HelloInput): String!
}

Expected

The relay compiler should be able to handle an extend input syntax that is in the GraphQL spec (3.3.2. Schema Extension).

Reproduce

https://github.com/GalvinGao/relay-compiler-not-implemented-reproduce

Clone and yarn install. Then, run yarn build:relay.

❯ yarn build:relay
yarn run v1.22.19
$ relay-compiler
[INFO] querying files to compile...
[INFO] [default] compiling...
thread 'main' panicked at 'not yet implemented: InputObjectTypeExtension', crates/schema/src/in_memory/mod.rs:770:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error Command failed with exit code 101.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

[alunyov]

Thanks for report. I think the issue here is a little more complex than just updates to the compiler. Our runtime code also have to figure out what to do with these input extensions.

Relay treats all extensions as client-only: we don't send client fields to the server (these fields are removed from the queries), for example.

Now what do we do with the input extensions in runtime? We would probably need to skip sending this fields to the server too, but that will require changing the way we handle variables (we'll need to also remove unused variables for these queries).

[GalvinGao]

We're using goent.io in which using extend input is actually the documented way. What I've done on my part to keep my development flowing is that we basically just used the introspected schema (in which does not contain extend input) instead of the raw schema that contains extend input. And to automate this process we used https://the-guild.dev/graphql/codegen/plugins/other/schema-ast.

I think we can use this idea as well, basically add another pre-processing step to merge those "extended" types together to the type it is extending, and let the compiler not needed to worry about those extended types down the road, since to my understanding it is completely equivalent to do so.