Cannot use interface implementation as a valid type

[charypar]

Let's say I have a schema for some translated content with a common interface for entries:

interface Entry {
  id: ID
  slug: String
  translations: [Entry]
}

type Page implements Entry {
  id: ID
  slug: String
  translations: [Page] # Page implements Entry, this should be ok
}

In graphql-js this errors, saying the translations on Page should be of type [Entry]. Since Page implements Entry and translations of a Page will only ever be Pages, this seems ok to me.

Tried the same with union types with the same result. It's not a disaster, I can widen it to the interface type and use a type fragment in queries, but it seems a little unwieldy.

Am I missing a reason why it's not valid to narrow down an interface type when implementing an interface which specifies a field of an interface type? (uh, sorry, can't make that sentence any simpler)

[leebyron]

Closing this since it was fixed in the Dec spec and has since been implemented in graphql-js!

We refer to this as covariant interface implementation. That is you have implemented the interface, but you just supplied a covariant type (Page is an Entry) instead of an invariant type (must be Entry and only Entry).

We started with invariant interface implementation mostly as a simplifying force. Adding this kind of type system rule can add complexity to the rest of the system by introducing new kinds of cases that validation needs to consider, but in this case the complexity added was not untenable and it is worth it to enable this kind of query.

[charypar]

Yay, awesome!