Support using the LSP with multiple projects in the same VS Code instance

[vinistock]

VS Code allows opening multiple projects simultaneously in the same instance. For these scenarios, we can't spawn the Ruby LSP at the top level.

Each project may be using different versions of the LSP or RuboCop and may also have different RuboCop configurations. For these scenarios, it may be necessary to spawn multiple servers, one for each project.

[ShPakvel]

@vinistock hi! Thank you for work on it. 🙇🏼 I am curious if there is a chance to release these improvement in near future?

I see that previous ruby extension is deprecated in favor of ruby lsp. And we have exactly these case (multiple projects with specifics in workspace of one product). So would be nice to know some details on these issue (e.g. priority, vague estimate) if possible.
Thanks in advance.

[sradu]

Running into the same issue for what it's worth.

[vinistock]

It's not our immediate priority right now as we're working on other things, so I cannot provide estimates. If anyone is looking to contribute this, we'd need to spawn a separate language server client for each project - given that each one may have different dependencies and configurations.

Spawning the multiple clients is probably the easy part, the difficult one is going to be re-modelling the status language item to account for the fact that multiple servers may be running.

Currently, it's the client that controls the language status item with statuses and configuration for the server. We'll probably need some entity above client - since we may be in situations where there's more than one client running. And we definitely don't want to just keep creating more and more status items for each client.

We'll need to think of a way in which we can display the status of each client. In terms of configuration, it might be weird to have the language status item change user settings when you are managing a specific client, so we probably want to rely on VS Code's workspace settings.

Similarly to Client, the Ruby and the Debugger objects will also need to be project specific - since you could be using different Ruby versions on each project. Without doing an exploration, I believe we need a new abstraction for Workspace, which glues together everything you need to spawn a Client - including Ruby and the Debugger.

[vinistock]

I have made a prerelease with multi-workspace support https://github.com/Shopify/vscode-ruby-lsp/releases/tag/v0.5.0.

If people want to give it a try, please provide feedback on this issue so that we can address it before a stable release.

You can install prerelease version of VS Code extensions by

• Going into the extensions tab
• Finding the extension you want to install a prerelease version
• Clicking the squares button to the left of the cog icon

[joelmoss]

Just tried and its working perfectly! thx loads!

[nexoff]

@vinistock thank you for that great update!
spot one potential issue. In case I have a folder in my workspace that is not a ruby project then I have the following error message:

Failed to activate asdf environment: Command failed: /usr/bin/zsh -ic 'asdf exec ruby -rjson -e "STDERR.printf(%{RUBY_ENV_ACTIVATE%sRUBY_ENV_ACTIVATE},
      JSON.dump({ env: ENV.to_h, ruby_version: RUBY_VERSION, yjit: defined?(RubyVM::YJIT) }))"'
No version is set for command ruby
Consider adding one of the following versions in your config file at 
ruby 3.1.4
ruby 3.2.1
ruby 3.2.2

as I understand ruby-lsp have the same initialization order as folders in workspace and we have something like:
ruby_project_1 - ruby-lsp works as expected
not_a_ruby_project_2 - this one raise an error
ruby_project_3 - ruby-lsp doesn't work for this project