Add Metals support about scala-cli HOT 3 CLOSED

favor BSP, only have Metals download the native CLI, and talk to it through BSP.

This is the right way. BSP is supposed to be the ultimate solution to IDE communication with "build system"; it was designed for that. The IDE should not have to know anything about a build system. Having Metals depend on parts of the CLI as a library defeats the whole purpose. The only reason Metals does something like that for sbt is that sbt has a very long history, and BSP was not always part of sbt. For any new work, we should favor BSP, otherwise we're only piling on more and more complexity on top of what we have.

from scala-cli.

Smooth integration with IntelliJ is also an important requirement IMO. That's why I think using BSP only should be the preferred solution. As soon as we have the Build Server Protocol and Discovery implemented we have support in Metals and IntelliJ.

The question is: what will be the long running BSP server? It could be:

• a JVM "scala-cli" server (no bloop)
• a native "scala-cli" server delegating compilation to Bloop
• Bloop using "scala-cli" internally (native or JVM) to configure itself

from scala-cli.

Closing this issue, Metals support has been there for quite some time now.

from scala-cli.