List supporting implementations

[svenefftinge]

It would be helpful to have a wiki page where we can list any efforts that are working on either a client side or a server side implementation of the protocol. It's a key information to convince people to use this API and currently hard to find. So far it seems like from your side vscode is the only client implementation and your JSON support is the only server implementation. What else are people working on?

[nadako]

I'm working on an implementation for Haxe language here https://github.com/vshaxe/haxe-languageserver/tree/master/src. It's not yet ready, but I'm planning to make it a separate lib, similar to how MS did it with vscode-languageserver-node.

EDIT: I started moving the protocol itself implementation into a separate lib: https://github.com/vshaxe/vscode-languageserver-haxe

[svenefftinge]

We are working on an implementation for Xtext here https://github.com/eclipse/xtext/blob/restructuring/plugins/org.eclipse.xtext.ide/src/org/eclipse/xtext/ide/server/LanguageServerImpl.xtend. Also we are doing a Java binding of the protocol, here https://github.com/TypeFox/ls-api/tree/master/io.typefox.lsapi/src/main/java/io/typefox/lsapi

[egamma]

(@dbaeumer) Here are some others server implementations that use the vscode language protocol

• C++ extension. The server is implemented in C++.
• PowerShell extension. The server is implemented in C#

Work in progress:

• PHP - lead by @felixfbecker

Under consideration

• Exposing the VS Code CSS/SASS/LESS language service using this protocol. The server will be implemented in TS.

[felixfbecker]

I was experimenting a with implementing a language server in PHP but didnt work for it for quite a while because I faced limitations in the PHP parser (it cannot parse incomplete code - which is crucial for autocomplete). Need to improve the parser before working on the language server further

[egamma]

@svenefftinge I forgot to mention that the 'server based' linters, that is, linters that are run in a server to avoid the restart overhead for each lint pass, are all using the VS Code language protocol:

• vscode-tslint
• vscode-eslint
• vscode-jscs
• vscode-jshint
• vscode-htmhint

They typically use the diagnostics subset of the protocol. vscode-eslint is also using code actions/quick fixes.

[dbaeumer]

The json support inside VSCode uses the protocol as well.

[dbaeumer]

The Crane - PHP plugin is based on the server protocol as well (the server is implemented in TS) https://marketplace.visualstudio.com/items?itemName=HvyIndustries.crane

[egamma]

I've started to a page with the protocol implementations.

Please use this issue to discuss additions/changes.

[svenefftinge]

@egamma Cool, thank you.

Some comments. The Java-binding we (TypeFox == Maintainer) are working on is not an implementation for the java language, but a Java implementation of the protocol. I.e. A redefinition of all the message types in Java, together with JSON de/serialization. Also we have defined Java interfaces for the service methods. So it doesn't really belong in the 'Languages' category.

Xtext is spelled with an upper case X :)

[svenefftinge]

Codenvy and TypeFox are also working on a client implementation for Eclipse Che. See https://github.com/eclipse/che/issues/1287

[nadako]

The link to Haxe thing is not a language server itself, but merely the protocol code (similar to MS's vscode-languageserver-node), the correct link would be https://github.com/vshaxe/haxe-languageserver

[egamma]

Thanks for the feedback I made another pass:

• added a section for SDKs of the protocol
• added a section with Editors/IDEs of the protocol
• corrected the contents based on the above feedback.

[georgewfraser]

https://github.com/georgewfraser/vscode-javac uses this protocol to provide Java language support

[egamma]

@georgewfraser thanks, I've updated the table.

[TylerJewell]

Codenvy is working on a JSON implementation of the language server protocol. Also, we will have full support for language server and debugging server protocol within Che workspaces. We are also working on a distributed language server registry. This will allow a user to open a remote workspace and a file with a certain extension. If that extension does not have a language server associated with it, we'll do a lookup to see if one is available for download and installation into a workspace. Each distribute workspace can have different sets of language servers installed.

[bruno-medeiros]

Do any of the server protocol implementations listed so far support being installed and ran stand-alone, that is, outside of VSCode?

I am contemplating writing a client implementation for Eclipse (not Che, but the regular Eclipse desktop IDE), possibly integrating that into MelnormeEclipse a framework for creating Eclipse-based IDEs. But for that I'd like a language server implementation that I could start on its own. (Preferably for a language I know, like Java or C++, but I'd take any mature server). For example, could this be done for the C++ language server?

[nadako]

I think all nodejs-based server can be easily started without vscode, you just start them with node and connect thru stdio.

[dbaeumer]

@bruno-medeiros: I think most of the servers are currently bundled with the corresponding VS Code extension. If we want to reuse these server outside VS Code we need to work on packaging them independently of VS Code. I like doing this, but the actual work as to come from the VS Code extension creators. As soon as there is a client to Eclipse & Eclipse Che I think there will be enough motivation for language server providers to do so.

[TylerJewell]

Also, language servers will need a way to advertise themselves to various tools. A tool provider will want to provide a lookup mechanism and potentially a file type to language server association. And ten each tool provider will have a different process for how to integrate the language server into the editor. VS Code handles this by wrapping each server with an extension. Che will address this by having a common extension that works for all language servers.

So for language servers to advertise themselves and potentially the IDE specific extensions that wrap them, they will need a registry to halt their versions and optional extension adapters.

Codenvy and Eclipse Che are going to build a system to support this. We will then allow language servers to publish and version themselves, and it will be accessible for free by any tool.

[usarid]

The RAML Workgroup is implementing a language server for RAML, based on an ongoing componentization of the API Workbench. The language server work will be done in a new repo. The API Workbench is powered by a TypeScript-based SDK for RAML that features a parser, syntax highlighting, autocompletion, refactoring, navigation, and other capabilities useful for API professionals. The SDK forms the basis for the API Workbench implemented in Atom, but also has a web version and is intended to be incorporated in various editors and IDEs such as Eclipse. As the SDK components are broken out, we will be incorporating them into a node-based server supporting the Language Server Protocol.

[nojvek]

Does #25 help regarding the effort?

Language servers working across IDE's is a win for everyone. Thanks for making this happen.

[spoenemann]

Please update the repository link for the Xtext language server to https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext.ide/src/org/eclipse/xtext/ide/server/LanguageServerImpl.xtend (moved to another repository)

[egamma]

@spoenemann done

[jared2501]

We are going to build a Groovy and SQL language server implementation over the next few weeks, with a Python one later down the road. I'll post links in the wiki to the code when we have an MVP up on github.

[david-driscoll]

We've added support for the languageserver protocol to omnisharp via the node module omnisharp-node-client. https://github.com/OmniSharp/omnisharp-node-client/blob/master/languageserver/server.ts

[egamma]

@david-driscoll this is great news, added a row for omnisharp to the wiki page.

[malekpour]

Acording to https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations there is a C# sdk/lib

work in progress by @davwil

Is there a repo somewhere?

[XVincentX]

Good morning @egamma!

Would it be possible to get my extension listed in your wiki?

vscode-apielements

[egamma]

@XVincentX added your extension, thanks for letting us know about it.

[natgabb]

Hi @egamma

Would it be possible for you to add this implementation to your list: groovy-language-server It is maintained by Palantir and it is still a work in progress.

[egamma]

@natgabb done, thanks for the pointers.

[kofno]

I'm building an implementation for Crystal Language.

https://github.com/kofno/scry

[gorkem]

@egamma we have not added https://github.com/gorkem/java-language-server to this list yet.

[gfrancischini]

@egamma, do you have any updates on the C# sdk?

Thanks

[egamma]

@gorkem done, thanks for the reminder.

[dbaeumer]

@daviwil could you comment on the C# protocol implementation.

[felixfbecker]

I restarted my work on a PHP language server. The language server itself is completely written in PHP, uses an event loop, has high test coverage and relies on nikic/PHPParser to build complex ASTs instead of the RegExp parsing that VS Code does. The language server is published on packagist so it can be used by any IDE. The thin vscode extension is here, I have not published it yet because it doesn't have any features so far.

I also wrote JSON-RPC handling as a seperate package, which can be found here. In opposite to existing PHP JSONRPC implementations does it support nested targets that the language server protocol uses (textDocument/didOpen is mapped to the didOpen method of the textDocument property) and recursively maps structured parameters to the right classes using jsonmapper.

The last time I started this the problem was that at the time PHPParser could not parse incomplete documents very well, which is essential for autocompletion. This was just recently implemented in 3.0alpha.

The protocol parsing is implemented (and unittested), the method dispatching is implemented (and unittested), initialize method works. The first feature I want to implement is documentSymbol because it is quite easy if you have an AST. I have not finished the implementation yet, but nevertheless I wanted to share my work so far with you.

[bruno-medeiros]

I've added to the wiki https://github.com/RustDT/RustLSP , an LSP SDK for use in Rust. Still work in progress.

I'm hoping also to build a dummy/mock LSP server implementation, just to help out test LSP clients.

[egamma]

@bruno-medeiros thanks for the update.

[ghost]

I have implemented a language server for OCaml/Reason in vscode-reasonml.

[akosyakov]

It is confusing to me to find Xtext among languages, of course there is a grammar language Xtext, but Xtext is not just a language but a framework to develop programming languages with a lot of features out of the box including the language server protocol support.

@egamma Could you add Xtext to the SDK section also as a framework to develop languages by default exposed via the language server protocol? And add a link to the official site in addition to LanguageServerImpl.

Honestly there should be a separate section for such tools, like language frameworks or platforms.

[sqs]

We (Sourcegraph) have implemented a Go language server at https://github.com/sourcegraph/go-langserver. Right now, it only supports textDocument/{hover,definition,references} and workspace/symbol (in addition to some of the file system notifications). There is a companion vscode extension for testing it out in vscode in the same repository.

[egamma]

@freebroccolo updated the table, thanks.

[egamma]

@akosyakov I've added a link to the official xtext site in he language server implementation table, that should clarify things. Thanks for the feedback.

[jrmuizel]

A language server implementation for rust is being implemented here: https://github.com/jonathandturner/rustls

[egamma]

@jrmuizel thanks, added to the table.

[davwil]

@egamma it looks like there's an typo in the table, i never had anything to do with this project. Could you correct that? I'm sure you wanted to tag someone else.

[egamma]

@davwil thanks I was close it is @daviwil, fixed.

[akosyakov]

There are opened issues for existing Editors and IDEs to support LSP: Monaco, Orion, Ace, CodeMirror and Intellij IDEA. It would be nice to get up-votes to bring more adopters on the tool side.

[sqs]

We moved the Go language server to its own repository at https://github.com/sourcegraph/go-langserver. Could you please update the URL to that? Thanks!