Dart-code: Investigate LSP

Created on 27 Jan 2018  路  4Comments  路  Source: Dart-Code/Dart-Code

Currently Dart Code contains a lot of code that maps from the analysis server API into the VS Code API. Since VS Code's APIs are specific to Code, this code is very specific and not re-usable. If we pushed this code into an LSP implementation then it could be shared by other editors that implement LSP (for example, Visual Studio has preview support for it).

Consuming LSP

VS Code

To consume LSP in VS Code you create an extension as normal and then use the vscode-languageclient package to create an adapter for VS Code to use to communicate with your server. The client can spawn the process or be provided with a function that returns a process or a set or input/output streams (see here).

For Dart Code, we would need to be able to communicate with the server for custom requests additional to what the LSP supports which can be done with custom messages.

Visual Studio

Note: "The Visual Studio LSP extension can only be installed on the preview channel of Visual Studio. You should not use the preview for production purposes."

To consume LSP in Visual Studio you would create an extension as normal (which currently has the LSP preview extension as a dependency) and then use the Microsoft.VisualStudio.LanguageServer.Client NuGet package to create an adapter for Visual Studio to communicate with your server.

Implementation

Based on the above, there would need to be a small amount of TypeScript to get VS Code (and a small amount of C# if doing the same in Visual Studio) to connect to an LSP implementation. This code is relatively minor and is just to spawn the server and hand off to the IDE. The IDEs should themselves advertise their capabilities to the server and communicate directly.

There are a number of possible ways to do this:

  1. Ship LSP protocol inside the analysis server in the SDK
    This would mean putting SDK-detection logic into the extension(s) rather than the LSP server and being tied to SDK release schedules
  2. Write the LSP server as a proxy that spawns the analysis server and communicates over STDIO
    This means we're adding an addition process in the middle, but we're still talking to the analysis server in the same way that we do today (doing it this way, the server could be written in another technology if we so wished - Dart seems like a good candidate but we'll need to code-gen protocol APIs from the spec)
  3. Ship the analysis server inside the extension(s) and host it directly inside the LSP server
    This eliminates the extra process but bloats the distribution and ties people to a specific SDK version
  4. Don't ship the analysis server in the extension(s) but load it from the SDK directly in-process
    I don't know if this would work - can you dynamically load modules from unknown paths?
    We'd need to ensure the API we use for creating the server in-process here is stable since the version at runtime could be newer than we had when we shipped the LSP server inside the extension(s)

Related Links

VS Code

Visual Studio

Most helpful comment

Also, other IDEs as Atom or Eclipse support the LSP.

If you would offer standard LSP support my team could try to integrate Flutter into the Eclipse IDE. I believe diverse tool support would be very beneficial for the adaption of Flutter.

All 4 comments

Also, other IDEs as Atom or Eclipse support the LSP.

If you would offer standard LSP support my team could try to integrate Flutter into the Eclipse IDE. I believe diverse tool support would be very beneficial for the adaption of Flutter.

By the way, there is a natebosch/dart_language_server repository on GitHub maintained by @natebosch. It seems reasonably active.

@rcjsuen Yeah, that's what I've been using for my experiments (I've sent some PRs this week) :-)

Investigation has been done, and I've started on adding LSP to the Dart analysis server. Progress is tracked here:

https://github.com/dart-lang/sdk/blob/master/pkg/analysis_server/tool/lsp_spec/README.md

I don't think we need this issue any more. The VS Code plugin may move to the LSP protocol in the future once it supports everything we need (either through official requests or custom requests) to avoid spinning up two copies of the server.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

CaferPoyrazoglu picture CaferPoyrazoglu  路  4Comments

mayorbyrne picture mayorbyrne  路  5Comments

FeimiSzy picture FeimiSzy  路  4Comments

ifredom picture ifredom  路  3Comments

awfin picture awfin  路  3Comments