[monaco-graphql] Improve autocomplete suggestions when editing type system definitions

[cshaver]

When editing type system definitions, the autocomplete suggestions aren't super helpful (and kinda hard not to accidentally trigger at the top-level of the document):

In this PR I've updated one of the examples (so I could play with this behavior) to have an editor for the SDL that gets loaded in, which is applied to the query editor upon editing (I've added fakeField in the screenshot):

🖼 Screenshot of modified example

And I've added some autocomplete suggestions for the right keywords at the top-level, plus keywords that go after extend:

🖼 Gif

This is still rough, but I wanted to get some feedback on distinguishing between documents that contain documents executable and type system.

@acao (not sure who else to tag!)

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: c11ebf51bf8fca083045c5ac8f8979a9ca6918fa

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

This PR includes changesets to release 8 packages

Name	Type
graphql-language-service	Minor
codemirror-graphql	Patch
@graphiql/react	Patch
graphiql	Patch
graphql-language-service-cli	Patch
graphql-language-service-server	Patch
monaco-graphql	Patch
vscode-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

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: cshaver / name: Cristina "Crit" Shaver (93109e1e1b8430d326f699650c553722609d7835, e9005c1970e7eebbd01aa1a573676c1ac01423ee, 9189f04a333a44c0b9851feff68c75d8780a84b7, 8e0c8853e6013675c0c299eefcba844877e79791, 6f71b0ac0bc1ab62d145204cf6fd1495f05ca3dd, aa2830739a4fa81de09db2989f511a6f8de362e9, 53402e1beed37e382da6a01edbbf8a90e91d4db6, 90c2b3189f674aca60e6e6388b111753c2c529ca, 0940898ae48e9c0e4bdb7c4427ca318616b932d1, d4c9aa937d2c98f162c4c40d9f14882ec59b6dc8)

[acao]

Thanks for this! This is right off the LSP roadmap

[acao]

I have a whole laundry list of improvements planned on this area! I want to make the language services work better without schema as well. Hope to make a new major version where they use a single object param and we can pass more options and make schema nullable!

[acao]

CC @jonathanawesome - just as a preview in case you're interested in the more obscure seeming parts of the monorepo - this is what I was referring to about monaco's closesness to LSP and lower overhead for changes compared to codemirror which is not LSP-esque, and UX prescribed like monaco. Here with very useful test coverage, we can unlock some really useful UX improvements for monaco-graphql, and this automatically works in vscode-graphql and every other IDE extension too!

[acao]

This is fantastic, and soooo close if the only thing blocking you are the CI issues:

1. yarn format because something is funky with the precommit hook again
2. codemirror-graphql tests are failing because you accidentally enhanced codemirror-graphql as a side effect 😆
3. CLA bot is mad but not telling you why specifically (because it wants the commits to be signed with the same email you signed the CLA with 😩 )

[acao]

tagging in @imolorhe as well, as he will probably appreciate this improvement that will land in both cm6 and cm6-graphql!

also @stonexer for LSP matters

[cshaver]

cc: @acao this should be ready now, but I'm not sure why the prettier check is failing; yarn lint seems to pass when running locally

[cshaver]

cc: @acao this should be ready now, but I'm not sure why the prettier check is failing; yarn lint seems to pass when running locally

ah, just had to rebase with main! 🎉

[acao]

@cshaver thank you for all of this, including cleaning up the examples! I think this looks ready to go, tests are all looking good.

I think for codemorror-graphql in 5 at least, we are actually overriding this I think? if we want to unlock this capability there we should look into this.

Wait - I just noticed something - extend input - I don't see that in the specs - only extend type.. hmm!!! Is there an RFC for extend input type somewhere? if so, if it's advanced enough then that's fine. Either way, I'm really excited someone has this feature somewhere 😃

[cshaver]

Wait - I just noticed something - extend input - I don't see that in the specs - only extend type.. hmm!!! Is there an RFC for extend input type somewhere? if so, if it's advanced enough then that's fine. Either way, I'm really excited someone has this feature somewhere 😃

@acao It is in the spec here! I was surprised to learn scalars can be extended as well to add directives!

[acao]

@cshaver i see it now! My method of searching for code examples caused me to miss it. Thanks for teaching me about the spec 😂

[cshaver]

@acao I don't have write access, so feel free to merge this whenever!

[acao]

Ok sounds good! The one thing I wanted to add to the changleog isn’t necessary

[acao]

@cshaver unfortunately we need to revert this