Dart-code: Investigar LSP

Actualmente, Dart Code contiene una gran cantidad de código que se asigna desde la API del servidor de análisis a la API de VS Code. Dado que las API de VS Code son específicas de Code, este código es muy específico y no se puede volver a utilizar. Si insertamos este código en una implementación de LSP, entonces podría ser compartido por otros editores que implementen LSP (por ejemplo, Visual Studio tiene soporte de vista previa para él).

Consumir LSP

Código VS

Para consumir LSP en VS Code, crea una extensión como de costumbre y luego usa el paquete vscode-languageclient para crear un adaptador para que VS Code lo use para comunicarse con su servidor. El cliente puede generar el proceso o recibir una función que devuelva un proceso o un conjunto de flujos de entrada/salida ( ver aquí ).

Para Dart Code, necesitaríamos poder comunicarnos con el servidor para solicitudes personalizadas adicionales a las que admite el LSP, lo que se puede hacer con mensajes personalizados .

Estudio visual

Nota: "La extensión LSP de Visual Studio solo se puede instalar en el canal de vista previa de Visual Studio. No debe usar la vista previa con fines de producción".

Para consumir LSP en Visual Studio, debe crear una extensión normal (que actualmente tiene la extensión de vista previa de LSP como una dependencia) y luego usar el paquete NuGet Microsoft.VisualStudio.LanguageServer.Client para crear un adaptador para que Visual Studio se comunique con su servidor.

Implementación

Según lo anterior, sería necesario que haya una pequeña cantidad de TypeScript para obtener VS Code (y una pequeña cantidad de C# si se hace lo mismo en Visual Studio) para conectarse a una implementación de LSP. Este código es relativamente menor y es solo para generar el servidor y pasarlo al IDE. Los IDE deben anunciar sus capacidades al servidor y comunicarse directamente.

Hay varias maneras posibles de hacer esto:

1. Envíe el protocolo LSP dentro del servidor de análisis en el SDK
   Esto significaría poner la lógica de detección de SDK en las extensiones en lugar del servidor LSP y estar vinculado a los cronogramas de lanzamiento de SDK.
2. Escriba el servidor LSP como un proxy que genera el servidor de análisis y se comunica a través de STDIO
   Esto significa que estamos agregando un proceso de adición en el medio, pero todavía estamos hablando con el servidor de análisis de la misma manera que lo hacemos hoy (al hacerlo de esta manera, el servidor podría estar escrito en otra tecnología si así lo deseamos). Dart parece un buen candidato, pero necesitaremos codificar las API del protocolo de generación de la especificación)
3. Envíe el servidor de análisis dentro de la(s) extensión(es) y alójelo directamente dentro del servidor LSP
   Esto elimina el proceso adicional pero infla la distribución y vincula a las personas a una versión SDK específica.
4. No envíe el servidor de análisis en la(s) extensión(es), sino cárguelo desde el SDK directamente en el proceso.
   No sé si esto funcionaría. ¿Puedes cargar módulos dinámicamente desde rutas desconocidas?
   Tendríamos que asegurarnos de que la API que usamos para crear el servidor en proceso aquí sea estable, ya que la versión en tiempo de ejecución podría ser más nueva que la que teníamos cuando enviamos el servidor LSP dentro de las extensiones.

enlaces relacionados

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

Código VS

• Documentos de VS Code: code.visualstudio.com/.../example-language-server
• Cliente de lenguaje VS Code: npm/vscode-languageclient
• Ejemplo de código VS: github.com/Microsoft/.../lsp-multi-server-sample/
• Funciones admitidas: code.visualstudio.com/...#_additional-language-server-features

Estudio visual

• Documentos de VS LSP docs.microsoft.com/.../language-server-protocol
• Anuncio de vista previa de LSP de VS blogs.msdn.microsoft.com/.../anounce-language-server-protocol-preview-release/
• Extensión de vista previa de VS LSP marketplace.visualstudio.com