Support configuring custom rspec command in VS Code

[westonkd]

ruby-lsp already does a good job of inferring the base rspec command to run based on the presence of a Gemfile or binstup.

This pull request allows further customization of the rspec command using the addonSettings VS Code configuration exposed by ruby-lsp

Check out the modifications to README.md for descriptions of the two newly-added configuration options (rspecCommand and useRelativePaths).

These two new options can be used in conjunction to solve issues like those described in #27 (using ruby-lsp-rspec with docker):

.vscode/settings.json

{
  "rubyLsp.addonSettings": {
    "Ruby LSP RSpec": {
      "rspecCommand": "docker compose exec app rspec",
      "useRelativePaths": true
    }
  }
}

[carlqt]

I was just thinking of contributing this same feature. Thanks!

Hope this get merges soon 🙏

[westonkd]

@st0012 Any thoughts on this feature or implementation? Thanks!

[westonkd]

I just hit another use case where the combination of the two settings I added here are not quite sufficient to get things working (Docker + a monorepo-style setup).

When I get time I'll push a change making the settings interface slightly more flexible than what I've added here.

[st0012]

Hi sorry for the delay. I understand the need of custom RSpec commands, but what's the problem useRelativePaths is going to solve?

From my experience, if the test files need to be run with a relative path, it usually indicates that the project should properly utilize VS Code's multi-root workspaces feature.

[westonkd]

👋 Hey! No problem for the delay, thanks for taking a look.

but what's the problem useRelativePaths is going to solve?
I was working in a development environment that:

• Used Docker containers to run the application in development
• Ran rspec within those same containers
• Ran VS Code extensions (like Ruby LSP) on the host machine, not within the container

With that setup, the spec file path was an absolute path pointing to the file on the host machine, not the path within the container.

One way to fix that was to add support for a relative path so the spec path was correct, even if it was generated on the host machine but used in a container.

I've thought more about that and don't think it's the right solution. Instead, using a Dev Container and running Ruby LSP extension in that container yields the correct spec paths without the need for an additional setting.

I've updated this pull request to add a bit of documentation to those who might be wondering how do do this in #27 .

I've additionally added a debug option to print the rspec commands generated for each code lense since it was helpful for me to troubleshoot my configuration and contribute. I'm fine leaving this bit out though if it does not feel generally helpful.