Open bigH opened 4 months ago
@louim how should we be providing configurations to the rails lsp app?
Thank you for the feature proposal. I'm curious, are you connecting VS Code to the container already? Here are the docs.
I expected that if VS Code was already connected to the container, then running bin/rails
would just work.
@vinistock I would also be interested in the possibility of swapping the run command. Our project use a custom bin/dev
wrapper for all commands to inject secrets from an external secret store. Currently I just forked the gem and swapped the command, but I'd be very interested in having the option to have that configurable. However, there's a few questions on how that would work. I think those questions are related to the ecosystem as a whole and I'd love to have your thoughts on it:
ruby-lsp-rails
in their gemfile to allow for easier updates. But what happen if you need specific config options for it..vscode
folder committed to the repo?The usual way of configuring things for language servers would be through editor settings. Indeed, shared configurations would happen through something like VS Code's workspace settings (.vscode/settings.json
).
The benefit is that deferring to editors for configuration allows them to provide a nicer experience. For example, VS Code will merge your user settings with the workspace settings for the current project you're working on, so you can both get project-wide defaults with your own preferences.
Regarding configuring Ruby LSP addons, we discussed this briefly within the team and I think the ideal solution would be to have a flexible object based on addon names. There's no way to know ahead of time which addons the developer may have installed, so we need the flexibility.
I'm thinking something like this:
// Your user/workspace settings
{
"rubyLsp.addons": {
"Ruby LSP Rails": {
"serverCommand": "bin/dev"
}
}
}
The server would then delegate the configurations to the right addons based on their unique names. We still need to implement this though, but if you're willing to take a stab at it we can definitely help with the details.
Is anyone actively working on this?
I can take the Ruby LSP configuration propagation and the Rails LSP design for the configuration.
@vinistock are you able to create an issue in the Ruby LSP repo? It would be useful to know any constraints you may have in mind for the addon config system.
I put up a PR for the first step of this, which is generally allowing addons to be configured by editor settings.
After that is shipped and released, the steps to conclude the work are:
ruby-lsp
gem to match the version in which the new functionality is releasedRuby LSP Rails
and define some new setting like runtimeServerCommand
or something along those lines. This should default to bin/rails
, which is what we currently have hard coded in the constantGetting fairly busy but will return to this soon (< 1 month).
We'd like to be able to configure the runner to support different ways of running the
server.rb
file.This is specifically important because our rails code runs inside Kubernetes containers while we develop. Running the Rails LSP on the local machine will come with massive efforts. We'd need to be able to support something like
cool-tool exec <container> -- bundle exec rails runner server.rb
.