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