Repository navigation
Support type extensions in DefinitionDocuments - #157
Open
swalkinshaw wants to merge 2 commits into
Open
swalkinshaw wants to merge 2 commits into
swalkinshaw wants to merge 2 commits into
Conversation
swalkinshaw
changed the title
swalkinshaw
force-pushed
the
support-schema-type-extensions
branch
from
October 23, 2026 20:05
f2112c3 to
2bc3d64
Compare
Parse the seven type system extensions of the September 2025 spec (`extend schema`, `scalar`, `type`, `interface`, `union`, `enum` and `input`). The parser keeps each extension as its own node, in source order, so that tools can read extensions as they are written. - An extension must add at least one part, cannot have a description and takes only const directives. Directive extensions are draft-only and are rejected. - Bluejay does not apply extensions to the types they extend. `SchemaDefinition::try_from` gives one descriptive error for each extension, as the spec allows for tools that only build schemas. It does not build a schema that differs from the document. - Type definitions can omit their body (`type Foo`, `union Foo`, ...), as the grammar allows. `try_from` applies the spec rule that each type must define one or more members. - Every definition and extension has a span from its description (or keyword) to its end. With the public `type_definitions()`, `schema_definitions()` and `type_system_extensions()` accessors and the `name_token()` and `description_token()` accessors, a tool can lower or edit schema source without scanning the text. `Name` and `StringValue` are exported so that callers can name these types. Documents without extensions parse as before. The spans add 8 bytes to each type and directive definition and nothing to fields, arguments or enum values.
Add benchmarks that parse the 3.4 MB admin schema, build a schema definition from it, and parse the same type bodies as definitions and as extensions.
swalkinshaw
force-pushed
the
support-schema-type-extensions
branch
from
October 26, 2026 17:36
2bc3d64 to
ad5d7d1
Compare
swalkinshaw
marked this pull request as ready for review
October 26, 2026 18:01
szluzero
approved these changes
Oct 27, 2026
szluzero
left a comment
szluzero
left a comment
There was a problem hiding this comment.
I don't know rust so just used an agent to review and found no blockers, and letting bluejay parse type extensions and bodyless types makes sense to me
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bluejay rejects
extend type Foo { … }andtype Foowith a parse error, but both are valid GraphQL (Type System Extensions, ObjectTypeDefinition). Bluejay now parses them, so that tools which read schema source see each extension as it is written.TypeSystemExtensioncovers the seven extension kinds of the September 2025 spec.DefinitionDocument::type_system_extensions()returns them in source order.extend directiveis in the draft spec only, and stays a parse error.SchemaDefinition::try_fromreturns one error for each extension. The spec allows this for tools that only build schemas, with "a descriptive error". Bluejay does not build a schema that differs from its document.type Foo,union Foo, …) now parse.try_fromapplies the "must define one or more fields / values / member types" rules from Type Validation.HasSpan, from its description (or keyword) to its end. Together with the publictype_definitions(),schema_definitions(),name_token()anddescription_token()accessors, a tool can lower or edit schema source without scanning the text.NameandStringValueare exported, so callers can name these types.Breaking: no public API is removed. A document with a bodyless type now fails in
try_frominstead of inparse.Cost: no measurable change in the existing parse benchmarks. Each type and directive definition is 8 bytes larger. Fields, arguments and enum values do not change size. An extension parses 2–7% slower than a definition with the same body, because of the extra
extendtoken.Out of scope: applying extensions to the types they extend, and the version bump.
Benchmarks (criterion medians, two runs of each side)
mainmainagainThe two
mainruns differ by up to 10%, so the differences betweenmainand this PR are noise.