The Ruby LSP is an implementation of the language server protocol for Ruby, used to improve rich features in editors. It is a part of a wider goal to provide a state-of-the-art experience to Ruby developers using modern standards for cross-editor features, documentation and debugging.
Want to discuss Ruby developer experience? Consider joining the public Ruby DX Slack workspace.
If using VS Code, all you have to do is install the Ruby LSP extension to get the extra features in the editor. Do not install this gem manually.
See editors for community instructions on setting up the Ruby LSP.
The gem can be installed by doing
gem install ruby-lsp
If you decide to add the gem to the bundle, it is not necessary to require it.
group :development do
gem "ruby-lsp", require: false
end
See the documentation for more in-depth details about the supported features.
- RubyConf 2022: Improving the development experience with language servers (Vinicius Stock)
- Remote Ruby: Ruby Language Server with Vinicius Stock
Bug reports and pull requests are welcome on GitHub at https://github.com/Shopify/ruby-lsp. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the Contributor Covenant code of conduct.
Run the test suite with bin/test
.
For more visibility into which tests are running, use the SpecReporter
:
SPEC_REPORTER=1 bin/test
By default the tests run with warnings disabled to reduce noise. To enable warnings, pass VERBOSE=1
.
Warnings are always shown when running in CI.
To simplify the way we run tests over different pieces of Ruby code, we use a custom expectations test framework against a set of Ruby fixtures.
We define expectations as .exp
files, of which there are two variants:
.exp.rb
, to indicate the resulting code after an operation..exp.json
, consisting of aresult
, and an optional set of inputparams
.
To add a new fixture to the expectations test suite:
- Add a new fixture
my_fixture.rb
file undertest/fixtures
- (optional) Add new expectations under
test/expectations/$HANDLER
for the request handlers you're concerned by - Profit by running
bin/test test/requests/$HANDLER_expectations_test my_fixture
- Handlers for which you added expectations will be checked with
assert_expectations
- Handlers without expectations will be ran against your new test to check that nothing breaks
- Handlers for which you added expectations will be checked with
To add a new expectations test runner for a new request handler:
-
Add a new file under
test/requests/$HANDLER_expectations_test.rb
that subclassesExpectationsTestRunner
and callsexpectations_tests $HANDLER, "$EXPECTATIONS_DIR"
where:$HANDLER
is the fully qualified name or your handler class and$EXPECTATIONS_DIR
is the directory name where you want to store the expectation files.# frozen_string_literal: true require "test_helper" require "expectations/expectations_test_runner" class $HANDLERExpectationsTest < ExpectationsTestRunner expectations_tests RubyLsp::Requests::$HANDLER, "$EXPECTATIONS_DIR" end
-
(optional) Override the
run_expectations
andassert_expectations
methods if needed. See the different request handler expectations runners undertest/requests/*_expectations_test.rb
for examples. -
(optional) Add new fixtures for your handler under
test/fixtures
-
(optional) Add new expectations under
test/expectations/$HANDLER
- No need to write the expectations by hand, just run the test with an empty expectation file and copy from the output.
-
Profit by running,
bin/test test/expectations_test $HANDLER
- Tests with expectations will be checked with
assert_expectations
- Tests without expectations will be ran against your new $HANDLER to check that nothing breaks
- Tests with expectations will be checked with
- Open the test file.
- Set a breakpoint(s) on lines by clicking next to their numbers.
- Open VS Code's
Run and Debug
panel. - At the top of the panel, select
Minitset - current file
and click the green triangle (or press F5).
- Open the
vscode-ruby-lsp
project in VS Code. - [
vscode-ruby-lsp
] Open VS Code'sRun and Debug
panel. - [
vscode-ruby-lsp
] SelectRun Extension
and click the green triangle (or press F5). - [
vscode-ruby-lsp
] Now VS Code will:- Open another workspace as the
Extension Development Host
. - Run
vscode-ruby-lsp
extension in debug mode, which will start a newruby-lsp
process with the--debug
flag. Note that debugging is not available on Windows.
- Open another workspace as the
- Open
ruby-lsp
in VS Code. - [
ruby-lsp
] Runbin/rdbg -A
to connect to the runningruby-lsp
process. - [
ruby-lsp
] Use commands likeb <file>:<line>
orb Class#method
to set breakpoints and typec
to continue the process. - In your
Extension Development Host
project (e.g.Tapioca
), trigger the request that will hit the breakpoint.
VS Code users will be prompted to enable the Code Spell Checker extension. By default this will be enabled for all workspaces, but you can choose to selectively enable or disable it per workspace.
If you introduce a word which the spell checker does not recognize, you can add it to the cspell.json
configuration alongside your PR.
The gem is available as open source under the terms of the MIT License.