Repository navigation
Type extensions aren't merged: union/enum/interface/scalar extensions replace the base type, directives on object/input extensions are dropped #552
Description
I want to suggest an idea and checked that ...
- ... to my best knowledge, my idea wouldn't break something for other users
- ... the documentation does not mention anything about my idea
- ... there are no open or closed issues that are related to my idea
Description
According to the June 2018 GraphQL spec, the following types may be extended in a GraphQL schema:
- Scalars
- Objects (type in SDL)
- Interfaces
- Unions
- Enums
- InputObjects (input in SDL)
The kotlin.graphql.kickstart.tools.SchemaParser.kt class currently supports extensions of Objects and InputObjects but it does not support extensions for Scalars, Unions, Enums, or Interfaces. The result is that extensions of these types are not respected when constructing the corresponding GraphQLTypes.
This new feature could be modeled after the existing behavior in the SchemaParser that currently separates ObjectTypeExtensionDefinitions and InputObjectTypeExtensionDefinitions.
Add logic to SchemaParser to treat ScalarTypeExtensionDefinitions, UnionTypeExtensionDefinitions, EnumTypeExtensionDefinitions, and InterfaceTypeExtensionDefinitions similar to ObjectTypeExtensionDefinitions and InputObjectTypeExtensions.
Use Cases
Support extending Scalar, Union, Enum, and Interfaces types throughout a schema.
Note: This opportunity for enhancement was discovered while attempting to extend a union type. I have not confirmed the behavior for Scalar, Enum, or Interface types but have included those types in this issue based on code inspection of the SchemaParser class.
Consider the following SDL:
union FooBar = Foo | Bar
extend union FooBar = Baz
The expectation is that FooBar would resolve to Foo | Bar | Baz. However, under the current implementation it resolves to Baz.
Activity
Sceri commentedon Jul 25, 2021
I can confirm that extending the interfaces doesn't work either. As a result, some fields will be missing in the interface definition, which creates bugs at runtime. It would be nice to throw an exception for features that are currently not supported when parsing the schema.
oryan-block commentedon Oct 3, 2026
Widening this to cover every type extension, since they all need the same fix: merge each extension into its base type in
SchemaParserandSchemaClassScanner. On master:union FooBar = Foo | Bar+extend union FooBar = Bazgives members[Baz].enum Color { RED }+extend enum Color { GREEN }gives values[GREEN].interface Node { id: ID }+extend interface Node { name: String }gives fields[name].type Product @key(fields: "upc")+extend type Product @key(fields: "name")keeps only the base@key. Fields fromextend type/extend inputare merged, but their directives are dropped:createObjectandcreateInputObjectonly read the base definition's directives.Union, enum, interface and scalar extensions are
*TypeDefinitionsubclasses, so they stay in the definition lists and replace the base definition (associateBy, last one wins) instead of merging into it. No error is raised.The dropped directives are the remaining gap from #345: federation entities declared with
extend type X @key(...)lose their key.[-]Add support for extending Scalar, Union, Enum, and Interface types in SchemaParser[/-][+]Type extensions aren't merged: union/enum/interface/scalar extensions replace the base type, directives on object/input extensions are dropped[/+]