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.

[st0012]

Thanks for the context 👍
I think we can apply these changes to make the CI pass:

diff --git a/lib/ruby_lsp/ruby_lsp_rspec/addon.rb b/lib/ruby_lsp/ruby_lsp_rspec/addon.rb
index 1719e8f..83136a0 100644
--- a/lib/ruby_lsp/ruby_lsp_rspec/addon.rb
+++ b/lib/ruby_lsp/ruby_lsp_rspec/addon.rb
@@ -14,7 +14,8 @@ module RubyLsp
     class Addon < ::RubyLsp::Addon
       extend T::Sig
 
-      attr_reader :debug, :rspec_command
+      sig { returns(T.nilable(String)) }
+      attr_reader :rspec_command
 
       sig { override.params(global_state: GlobalState, message_queue: Thread::Queue).void }
       def activate(global_state, message_queue)
@@ -22,7 +23,7 @@ module RubyLsp
 
         settings = global_state.settings_for_addon(name)
         @rspec_command = T.let(settings&.dig(:rspecCommand), T.nilable(String))
-        @debug = T.let(settings&.dig(:debug) || false, T::Boolean)
+        @debug = T.let(settings&.dig(:debug) || false, T.nilable(T::Boolean))
       end
 
       sig { override.void }
@@ -44,7 +45,7 @@ module RubyLsp
       def create_code_lens_listener(response_builder, uri, dispatcher)
         return unless uri.to_standardized_path&.end_with?("_test.rb") || uri.to_standardized_path&.end_with?("_spec.rb")
 
-        CodeLens.new(response_builder, uri, dispatcher, rspec_command: rspec_command, debug: debug)
+        CodeLens.new(response_builder, uri, dispatcher, rspec_command: @rspec_command, debug: T.must(@debug))
       end
 
       sig do
diff --git a/spec/code_lens_spec.rb b/spec/code_lens_spec.rb
index c3d6883..c0a4974 100644
--- a/spec/code_lens_spec.rb
+++ b/spec/code_lens_spec.rb
@@ -164,7 +164,7 @@ RSpec.describe RubyLsp::RSpec do
     context "with a custom rspec command configured" do
       let(:configuration) do
         {
-          rspecCommand: "docker compose run --rm web rspec"
+          rspecCommand: "docker compose run --rm web rspec",
         }
       end
 
@@ -192,7 +192,7 @@ RSpec.describe RubyLsp::RSpec do
             },
           )
 
-          response = server.pop_response.response
+          response = pop_result(server).response
           expect(response[0].command.arguments[2]).to eq("docker compose run --rm web rspec /fake_spec.rb:1")
         end

Can you also update PR description to reflect the latest changes? Thanks.

[westonkd]

Done. Thanks @st0012 !

Running rspec, rubocop and sorbet tc are passing for me locally now. I'll keep an eye out for the results of the action once it runs.

[st0012]

Thanks 👍

[pprotas]

Very unfortunate the relative path feature got reverted, I could really use this! Shopify/ruby-lsp#2965

My setup has the rails server running in Docker, but the VSC instance is local (not using devcontainer). Relative paths for test runners would really solve my issues.