-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support using the LSP with multiple projects in the same VS Code instance #1510
Comments
@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. |
Running into the same issue for what it's worth. |
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 |
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
|
Just tried and its working perfectly! thx loads! |
@vinistock thank you for that great update!
as I understand ruby-lsp have the same initialization order as folders in workspace and we have something like: |
Thank you for the feedback! The latest commit on the PR addresses that issue. |
@vinistock I'm a bit unclear how this solves the issue that was solved in Shopify/vscode-ruby-lsp#877 - if i open the root directory of a project:
Is this patch intended only for multi root workspace scenarios? (tested with pre-release version and debugged with 0.5.0 from code locally) |
You need to open |
For future readerrs, here is the setup working for me (with 0.5.0) -
This prevents duplication of folders in "root" (there are a few files there). This still installs .ruby-lsp in both root and server. However if I change the order of the folders in the workspace so that root is last, format on save breaks. |
I also have a project repo with the Ruby code in a subdirectory, just like @jprosevear. I have the same concern with planning for only this fix. For me, this and Shopify/vscode-ruby-lsp#877, where there is a setting where the Ruby code root directory can be specified, are necessary. A multi-root project is great and necessary. (I need this too.) However, it is still desirable to open just the project directory. |
Please see my answer in Shopify/vscode-ruby-lsp#877 (comment). |
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.
The text was updated successfully, but these errors were encountered: