Configurable runner for LSP backend

[bigH]

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.

Tasks

Beta Give feedback

1. Determine how to configure runner command
2. Implement runner command configurability

[bigH]

@louim how should we be providing configurations to the rails lsp app?

[vinistock]

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.

[louim]

@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:

• How would one define configuration for extensions to the main LSP, if the LSP in automatically injecting said extensions? Eg. in this case, the end goal is to remove the need for application to include ruby-lsp-rails in their gemfile to allow for easier updates. But what happen if you need specific config options for it.
• How would those config be shared with the repository? In this case the config is not a personal user preference, so ideally it would be configured per project, not per user. Would it be a specific config file that the LSP would read? Or included in the .vscode folder committed to the repo?

[vinistock]

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.

[bigH]

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.

[vinistock]

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:

• Bump our minimum requirement of the ruby-lsp gem to match the version in which the new functionality is released
• Start reading the settings for Ruby 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 constant
• Then we use the configured command and get rid of the constant

[bigH]

Getting fairly busy but will return to this soon (< 1 month).