Dart-code: Investigar LSP

Atualmente, o Dart Code contém muito código que mapeia da API do servidor de análise para a API do VS Code. Como as APIs do VS Code são específicas do Code, esse código é muito específico e não reutilizável. Se enviarmos esse código para uma implementação de LSP, ele poderá ser compartilhado por outros editores que implementem o LSP (por exemplo, o Visual Studio tem suporte de visualização para ele).

Consumindo LSP

Código VS

Para consumir o LSP no VS Code, você cria uma extensão normalmente e, em seguida, usa o pacote vscode-languageclient para criar um adaptador para o VS Code usar para se comunicar com seu servidor. O cliente pode gerar o processo ou receber uma função que retorna um processo ou um conjunto ou fluxos de entrada/saída ( veja aqui ).

Para o código Dart, precisaríamos poder nos comunicar com o servidor para solicitações personalizadas adicionais ao que o LSP suporta, o que pode ser feito com mensagens personalizadas .

Estúdio visual

Observação: "A extensão Visual Studio LSP só pode ser instalada no canal de visualização do Visual Studio. Você não deve usar a visualização para fins de produção."

Para consumir o LSP no Visual Studio, você criaria uma extensão normalmente (que atualmente tem a extensão de visualização do LSP como uma dependência) e, em seguida, usaria o pacote NuGet Microsoft.VisualStudio.LanguageServer.Client para criar um adaptador para o Visual Studio se comunicar com seu servidor.

Implementação

Com base no exposto, seria necessário haver uma pequena quantidade de TypeScript para obter o VS Code (e uma pequena quantidade de C# se fizer o mesmo no Visual Studio) para se conectar a uma implementação de LSP. Esse código é relativamente pequeno e serve apenas para gerar o servidor e passar para o IDE. Os próprios IDEs devem anunciar seus recursos ao servidor e se comunicar diretamente.

Existem várias maneiras possíveis de fazer isso:

1. Envie o protocolo LSP dentro do servidor de análise no SDK
   Isso significaria colocar a lógica de detecção do SDK na(s) extensão(ões) em vez do servidor LSP e estar vinculado aos cronogramas de lançamento do SDK
2. Escreva o servidor LSP como um proxy que gera o servidor de análise e se comunica por STDIO
   Isso significa que estamos adicionando um processo de adição no meio, mas ainda estamos conversando com o servidor de análise da mesma forma que fazemos hoje (fazendo assim, o servidor pode ser escrito em outra tecnologia se assim o desejarmos - Dart parece ser um bom candidato, mas precisaremos codificar APIs de protocolo de geração a partir da especificação)
3. Envie o servidor de análise dentro da(s) extensão(ões) e hospede-o diretamente dentro do servidor LSP
   Isso elimina o processo extra, mas sobrecarrega a distribuição e vincula as pessoas a uma versão específica do SDK
4. Não envie o servidor de análise nas extensões, mas carregue-o do SDK diretamente no processo
   Não sei se isso funcionaria - você pode carregar módulos dinamicamente de caminhos desconhecidos?
   Precisamos garantir que a API que usamos para criar o servidor em processo aqui seja estável, pois a versão em tempo de execução pode ser mais recente do que tínhamos quando enviamos o servidor LSP dentro da(s) extensão(ões)

Links Relacionados

• Site LSP: microsoft.github.io/language-server-protocol

Código VS

• Documentos do VS Code: code.visualstudio.com/.../example-language-server
• Cliente de idioma do VS Code: npm/vscode-languageclient
• Exemplo de código VS: github.com/Microsoft/.../lsp-multi-server-sample/
• Recursos suportados: code.visualstudio.com/...#_additional-language-server-features

Estúdio visual

• VS LSP docs docs.microsoft.com/.../language-server-protocol
• Anúncio de visualização do VS LSP blogs.msdn.microsoft.com/.../announcing-language-server-protocol-preview-release/
• Extensão de visualização do VS LSP marketplace.visualstudio.com