La elección de un editor, un IDE o cualquier otra herramienta de desarrollo se acaba convirtiendo en una decisión personal del programador. Todos tenemos nuestras herramientas favoritas que variamos según sea la naturaleza del proyecto o el lenguaje de programación que usemos.
Las herramientas de desarrollo más importantes son las que controlan el ciclo de
compilación, test y ejecución, como pueden ser maven, gradle, sbt o
mill, por sólo citar algunas de las usadas normalmente en scala. Estas
herramientas condicionan cómo se estructura nuestro proyecto y cómo realizar las
tareas más habituales durante el desarrollo.
Cada IDE se las ingenia para extraer de un proyecto toda la información necesaria para la compilación, detectando los directorios con código que presenta como espacio de trabajo (workspace) donde el programador pueda trabajar, ver, escribir y compilar el código. Si puede, extrae esta información de las herramientas de desarrollo, aunque no siempre es posible.
Muchas veces, el soporte que da un IDE a un determinado lenguaje, a una librería o a una plataforma no es todo lo completo posible. Muchas veces el soporte era parcial, sólo el coloreado de sintáxis y poco más. En otras, la detección de errores se quedaba corta y había que acudir a una compilación manual para detectar los errores más arcanos. Era casi imposible tener un IDE completo que se pudiera usar con cualquier lenguaje y librería, por lo que era obligando el cambio entre editores, IDEs y herramientas buscando el mejor soporte.
LSP - Language Server Protocol
Para racionalizar esta situación, Microsoft sacó el Language Server Protocol (LSP). Basado en una arquitectura cliente-servidor, los editores e IDEs pasan a ser clientes de servidores LSP, uno para cada lenguaje, comunicándose con ellos a través de un protocolo común. Gracias a los servidores LSP se hacen tareas tan comunes como el resaltado de sintáxis, autocompletado, localización de errores de sintáxis, formateo de código, búsqueda de referencias, etc. Además, los propios creadores de los lenguajes vigilan la calidad de estos servidores, lo que aporta mayor fiabilidad.
Existen implementaciones para muchos lenguajes. IDEs como Visual Code instalan estos servidores LSP junto al instalar la extensión del lenguaje que vayamos a usar, por lo que no requiere instalarlos manualmente. Lo importante es saber que podemos usar el mismo servidor en cualquier editor e IDE que soporte el protocolo LSP.
BSP - Build Server Protocol
Desarrollando la idea de LSP, surge el Build Server Protocol (BSP) como colaboración entre el Scala Center y JetBrain. La interacción entre el IDE y las herramientas de desarrollo se llevan a una arquitectura cliente-servidor. El servidor BSP siempre está corriendo de fondo y será quien se encargue de informar al IDE sobre la estructura del proyecto, dónde están los errores de compilación o enlazado, del resultado de los test, etc.
Metals
Metals es un servidor LSP para scala y es, además, un cliente BSP. Controla todo el ciclo de desarrollo, desde la creación de un proyecto usando una plantilla, su compilación, prueba y ejecución, y su depurado.
metals puede usar como servidores BSP:
- bloop, el servidor BSP por defecto en metals
- sbt server (sbtn), incluído con la herramienta
sbt(aunque tiene algunos fallos aún en su última versión1.5,5)
Si usas sbt regularmente, igual te conviene usar su servidor para evitar
incoherencias en la compilación. Pero bloop es algo más rápido, más fiable y
se puede usar también con más herramientas como maven, gradle y mill. Mi
recomendación es dejar que metals te recomiende qué usar.
DAP - Debug Adaptar Protocol
Todavía hay algo más. Se está trabajando en un protocolo denominado Debug Adaptar Protocol (DAP) que estandariza las tareas de ejecución, testing y depurado. Basta añadir un adaptador DAP para que podamos usar nuestro IDE en tareas de depurado para ese lenguaje.
bloop implementa por defecto el protocolo DAP. Esta implementación ha sido sacada como plugin de sbt, sbt-debug-adapter, que ahora se puede usar con otras herramientas scala. En concreto, se puede usar con el servidor sbt.
Usando metals, la configuración para DAP es automática, uses bloop o sbtn, por lo que no tienes que preocuparte de configurar nada.