buildASTSchema() should throw on encountering `extend` definition

[leebyron]

buildASTSchema() exists to parse a fully complete schema definition and produce a schema. However currently if it encounters an extend definition, or any other definition it does not use for that matter, it silently skips over it. This can lead to a confusing debugging situation.

Instead, buildASTSchema() should throw when it encounters a definition that it does not use, similar to how execute() throws if a the provided document contains any definition other than operations.

[OlegIlyenko]

Out of curiosity: is there something that prevents supporting extend in buildASTSchema?

For example this definition:

type Queries {
  querySubset: QuerySubset
}

type Query {
  queries: Queries
}

extend type Queries {
  hello: String
}

Look semantically correct to me. When used in this form in may look a bit unusual, but the last definition could be loaded from a different file. From what I can tell, supporting extend does not have any downsides and provides more flexibility.

[leebyron]

That would be new behavior, but I'd also be happy to entertain PRs adding that as well. If so, the same change should probably be made in extendSchema if multiple extend statements are found, and care should be put into ensuring that the order in which the extensions are applied result in the same output.

[dyst5422]

I think this might be a breaking change for graphql-tools. I believe the way it currently does schema extension concatenates a number of schema language strings together and then pulls the extensions out to add them in a second step.

I agree with @OlegIlyenko about looking for a solution that handles the extensions and perhaps warning on this case in the mean time.

[kaushik94]

Hey I would like to chip in on this one. Can I first take up the issue of adding a warning? Then I will try to understand and help implement handling extend statement?

[viztor]

Does extend work now? @leebyron
or do we expect them to work maybe in the future?

The upside I'm seeing is as such allowing people building graphql application to modularize their application schema.

[IvanGoncharov]

Does extend work now?

@viztor Not at the moment but I plan to implement it for 14.1.0 release.
Currently, buildSchema/extendSchema is under heavy refactoring with the goal to implement #1389.

[langpavel]

For usecase where somebody needs multiple files merge up to one AST I write this helper: https://gist.github.com/langpavel/9653b99afe993167fc4bacafbfcc7909
Feel free to use it as an example of implementation which merge extend types into defined ones. Of course WITHOUT ANY WARRANTY :-)

What it can do:

• load multiple *.gql files
• parse them
• merge definitions into one Document
• sort definitions by multiple criteria
• print AST like concatenated SDL
• merge extend nodes into definition nodes, so AST looks like extended FTW
• you can print this AST into SDL file of course
• you can run buildASTSchema on merged AST →
• you can execute introspection query on it

really not much of code with this possibilities, look on gist :-)
BTW: I care about location and Sources