Support for multiple BSP connections

[Gedochao]

Is your feature request related to a problem? Please describe.

Metals currently supports only a single BSP connection at one time, even though the protocol allows for multiple connections.

Let's look at the following scenario:

.
├── app1
│   ├── .bsp
│   │   └── scala-cli.json
│   └──  ...
├── app2
│   ├── .bsp
│   │   └── scala-cli.json
│   └──  ...
└── scripts
    ├── .bsp
    │   └── scala-cli.json
    └──  ...

There are 2 apps and a scripts folder here, each with their own, separate classpath. For whatever reason they have some shared context and are kept in one repository for convenience. However, it is currently impossible to import them all at once as a single, multi-bsp-module project in Metals.

Another use case would be to mix and match the imported builds, possibly not just in the scope of BSP. As in, it could become a common usecase to keep an SBT-build app alongside a directory Scala CLI scripts. You'd want to be able import them all at once as well, having code completions, builds and everything else working nicely.

.
├── build.sbt
├── project
│   └── build.properties
├── scripts
│   ├── .bsp
│   │   └── scala-cli.json
│   └── ...
└── src
    ├── main
    │   └── scala
    │       └── ...
    └── test
        └── scala
            └── ...

Describe the solution you'd like

It would be optimal for Metals to support 3 usecases (supporting any of which shouldn't contradict supporting the others)

• multiple BSP connections, where each connection is defined in a separate sub-directory
  • each sub-directory has its own .bsp directory with the corresponding connection jsons
  • these connections should be detected by Metals and the user should be able to decide on his own, which are to be imported
  • this is currently being supported by IntelliJ btw, although the import is completely manual for the moment, with no automation

.
├── app1
│   ├── .bsp
│   │   └── scala-cli.json
│   └──  ...
├── app2
│   ├── .bsp
│   │   └── scala-cli.json
│   └──  ...
└── scripts
    ├── .bsp
    │   └── scala-cli.json
    └──  ...

• multiple BSP connections, where all the connections are defined in separate json files, but are all placed in the workspace root directory
  • this of course has to respect the rules as defined by BSP
    • this means that build scopes for each connection cannot overlap, of course
  • this setup possibly could be imported automatically (without prompting the user), when the root workspace directory is opened in Metals, to simplify the import

.
├── .bsp
│   ├── scala-cli-app1.json
│   ├── scala-cli-app2.json
│   └── scala-cli-scripts.json
├── app1
│   └──  ...
├── app2
│   └──  ...
└── scripts
    └──  ...

• a BSP connection alongside another build tool import, i.e. SBT
  • this would make it easier for SBT, Maven or Gradle users to adopt Scala CLI scripting

.
├── build.sbt
├── project
│   └── build.properties
├── scripts
│   ├── .bsp
│   │   └── scala-cli.json
│   └── ...
└── src
    ├── main
    │   └── scala
    │       └── ...
    └── test
        └── scala
            └── ...

Describe alternatives you've considered

I have suggested supporting multiple connections defined within a single json file for BSP in build-server-protocol#337, but despite the potential gains that would bring (lack of ambiguity for automatic, no-prompt import), it doesn't seem likely it will become supported. To be fair, it would probably also bring its own set of problems (i.e. could there be connections coming from multiple BSP servers defined in a single json? which build tool would then be responsible for keeping this json up-to-date and consistent?)

There's been some offline discussions on multiple jsons in a single .bsp directory in workspace root VS multiple.bsp directories in subdirs, and in the end there seems to be no clear reason to favor one over the other. Instead, probably both should be supported eventually, for flexibility's sake. Backwards compat in existing solutions may also be factored in (as IntelliJ already supports .bsp in subdirs, but not the other).

Additional contex

BSP docs actually recently didn't allow for multiple connection definitions to be present in one .bsp root, but it turned out to be without a clear reason and has been since updated: build-server-protocol#345

The corresponding ticket for Scala CLI: scala-cli#1153

Search terms

bsp multiple connections modules scala-cli