Proposal: More LSP friendly package names

[acao]

We're working to further LSP-ify our language services and server in preparation for monaco and an improved LSP interface and experience (see: https://github.com/graphql/graphiql/project/6).

(Edit: Revised, as npm will not allow us to publish both graphql-language-service and graphql-languageservice)

Overall, we need graphql-language-service to refer to a runtime agnostic service, and for the CLI to become another package with an explicit name, such as graphql-language-service-cli

Deprecating the binary

To transition users from the graphql bin included in graphql-language-service, the new graphql-language-service package will include a bin temporarily that just stderrs to install the new cli package, as I've seen webpack do.

CLI Usage Notes

The GraphQL Language Service has taken off in terms of usage, however by comparison to our other packages in the monorepo it's still the least installed. That said, it's often installed as a global bin, so usage will be different.

Also, to note, I've seen a few implementations of it that bundle the packaged bin manually with whatever IDE plugin that uses it, as their actual IDE plugin code is written in python, lua, etc.

So, a significant amount of users could be impacted by this.

Renaming the bin

Another consideration is renaming the bin itself. graphql bin path is being used by graphql-cli, which we may end up using/reccomending for scaffolding plugins. After working with a wide range of IDE extension developers (not just vscode devs), LSP is very descriptive.

So, I reccomend changing the bin as such:

graphql => graphql-lsp

[rebornix]

consider a full document persistence layer in the language service, alongside the cacheing

Maybe you are considering doing that: once having a document cache in the language server side, you may want to turn on document incremental sync mode to reduce the communication payload.

Besides, if you don't want to implement a document store yourself, you can use the VS Code one https://github.com/microsoft/vscode-textbuffer .

[acao]

oh brilliant, even better

currently we cache things like directives, definitions, etc, so whole files seems the logical next step, so that each implementation doesn't need to worry about that

[acao]

also from @rebornix, for posterity's sake:

I like the idea of aligning the name LAN-languageservice and Monaco-graphql. I was confused the very first time when I tried graphql ls code as I thought it's platform (browser/node) agnostic.

[acao]

@rebornix had this same experience with a few other devs who were LSP familiar, good to know this matters from the vscode side

[acao]

done!