Parse extend schema correctly when root operations list is absent

[trevor-scheer]

The online parser currently expects to parse a schema extension the same way it parses a schema definition, however the rules vary slightly in that the list of root operations can be omitted.

This change treats them as two distinct rules, allowing the list to be optional in extend case.

[changeset-bot]

🦋 Changeset detected

Latest commit: b0942f9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
graphql-language-service	Patch
codemirror-graphql	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 65.35%. Comparing base (9f725b8) to head (b0942f9).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3670      +/-   ##
==========================================
+ Coverage   65.32%   65.35%   +0.02%     
==========================================
  Files         122      122              
  Lines        7003     7003              
  Branches     2260     2265       +5     
==========================================
+ Hits         4575     4577       +2     
+ Misses       2411     2409       -2     
  Partials       17       17              

Files with missing lines	Coverage Δ
...kages/graphql-language-service/src/parser/Rules.ts	97.27% <ø> (+1.81%)	⬆️

[trevor-scheer]

@acao @yaacovCR would either of you be the right person to ping to get eyes on this? I've just updated this PR from a reproduction to a fix and would love to get this reviewed. Thanks in advance!

[yaacovCR]

Sorry @trevor-scheer — I am not familiar with the code base here. Just have contributed what I could to get incremental delivery moving…

[trevor-scheer]

Hey @acao, is there anything I can do to help move this along?

[benjie]

This looks correct to me, the tests look sensible.

However; it looks like the same issue applies to object, interface, enum and input object extensions?

Actually... for those, it looks like the {...} should be optional in all cases (extension and original definition), though they appear to be required in this parser definition? It's not immediately obvious to me why schema doesn't follow that same pattern, e.g. if you can have

input Foo @oneof
scalar Bar
extend input Foo {
  int: Int
  bar: Bar
}

why could you not also have:

schema @blah
type Query {
  int: Int
}
extend schema {
  query: Query
}

Perhaps this warrants a spec tweak. That's out of scope for this PR though!

I'm unfamiliar with the parser, so I defer to someone more familiar.