<Ruby>: <Suggest to use Solargraph instead of RubyLSP>

[SumonGFC]

Checks

• [X] This is not a duplicate of an existing issue (please have a look through our open issues list to make sure)
• [X] I have thoroughly read and understand The Odin Project Contributing Guide
• [x] Would you like to work on this issue?

Describe your suggestion

An issue that has often come up in discord conversations is getting RubyLSP to work in VScode. Although it does work 'out of the box' most of the time, people run into issues triggering it, getting it to work with RuboCop, and people also are let down by the fact that RubyLSP does not provide support (yet?) for core and standard library completion/intellisense.

I think it might be better to suggest that we install and use solargraph instead of RubyLSP (or perhaps use both). It has been my experience that installing and using solargraph is much smoother than RubyLSP.

Relevant lessons (there are 4):

1. https://www.theodinproject.com/lessons/ruby-installing-ruby#extras
2. https://www.theodinproject.com/lessons/ruby-debugging#assignment (part 3)
3. https://www.theodinproject.com/lessons/ruby-project-management#ruby-lsp-in-vscode
4. https://www.theodinproject.com/lessons/ruby-linting-and-rubocop#wouldnt-it-be-nice-to-have-all-this-in-vsc

(edit: added fourth link above)

Path

Ruby / Rails

Lesson Url

https://www.theodinproject.com/lessons/ruby-installing-ruby#extras

(Optional) Discord Name

Chindiana Jones

(Optional) Additional Comments

Discord Conversations about RubyLSP being confusing: https://discord.com/channels/505093832157691914/543074220691947531/1278014060167827496 https://discord.com/channels/505093832157691914/543074220691947531/1273651382313943174 https://discord.com/channels/505093832157691914/543074220691947531/1269495926045671474 https://discord.com/channels/505093832157691914/543074220691947531/1264966293048528936 https://discord.com/channels/505093832157691914/543074220691947531/1254073666619047936 https://discord.com/channels/505093832157691914/543074220691947531/1249058145284788365

[JoshDevHub]

Is solargraph still able to transmit suggestions, diagnostics, etc. to VSCode when there isn't a maintained VSCode plugin to support it?

[SumonGFC]

@JoshDevHub Admittedly, I didn't check this because I don't even use VSCode (I'm obliged to tell you I use neovim btw). But I really should have.

The solargraph vscode extension is able to transmit diagnostics to the editor. It does require 2 configuration steps however: making a solargraph.yml configuration file and adding rubocop as a reporter, and adding solargraph.diagnostics: true to user JSON settings. This does mean that rubocop is required for diagnostics (as far as I have been able to see).

The RubyLSP extension does feel like it has better linting and diagnostics compared to the solargraph extension, does not require rubocop gem to emit warnings/errors/etc., and the semantic highlighting is also really nice. This, in addition to the comment in this rejected PR that I just found, https://github.com/TheOdinProject/curriculum/pull/22445 , makes me think that solargraph is actually not the way to go.

Instead, to address the common "how do i get ruby-lsp to work" questions, it would probably be a good idea to add a section in the "Installing Ruby" lesson about how to set-up and trigger Ruby-LSP in VSCode. Currently, the "Installing Ruby" lesson just mentions the extension as an "Extra" thing to install if they want.

[github-actions[bot]]

This issue is stale because it has had no activity for the last 30 days.

[SumonGFC]

I was hoping that someone with more experience using RubyLSP with VScode might help resolve this issue. Instead I will propose a change:

Add the following instructions after this parargraph:

""" RubyLSP was designed to work with entire projects. The extension does a lot of work to detect information about the directory and files that Visual Studio Code was opened with. This can cause the RubyLSP extension to take some time getting started, and even not work at all if certain project files are missing. Going forward, it will be a good idea to follow these instructions before working on your own ruby code:

1. Create a new directory and cd into it:

mkdir ruby_project && cd ruby_project

2. Create a Gemfile and a Gemfile.lock.

touch Gemfile && touch Gemfile.lock

We will learn about what these files are later in the course. Essentially, we use these files to specify external dependencies and ruby libraries to leverage the power of code that other developers have written. You can just leave these empty for now. RubyLSP will use these files to initialize itself.

3. Create your ruby file(s)

touch main.rb

4. Open Visual Studio Code in our project directory

code .

Then open (click on) the main.rb file in the file explorer so that it opens in the editor. If all is well, RubyLSP will successfully initialize after a few minutes. There are 2 ways you can tell that the extension is working properly:

1. The extension will automatically create a .ruby-lsp folder in your project directory containing various configuration files.
2. You can also hover over the "Editor Language Status" symbol, (it's the {} button in the bottom right of the editor) - this will display several messages about the current editor language, including the status of RubyLSP (when we have a ruby file open in the editor).

If the extension has not started after a few minutes, you can try to restart it by opening the command palette and search for "Ruby LSP restart".

""""

This is quite long (and rough). I would appreciate some feedback on this. Note: I use touch Gemfile... instead of bundle init and bundle install to avoid explaining what bundler is.

[github-actions[bot]]

This issue is stale because it has had no activity for the last 30 days.

[SumonGFC]

@JoshDevHub sorry to ping you, just wondering what the status of this issue is. Perhaps you didn't see my previous comment where I included a suggestion. I also recently had the thought that my above tips could be put in one of those drop-boxes (like the instructions for Ruby installation for Linux/MacOs in the same lesson).

[github-actions[bot]]

This issue is stale because it has had no activity for the last 30 days.

[JoshDevHub]

Apologies for taking a while to get back to this. I think I'm going to close this unless I'm missing something. Feel free to leave a comment if you think so, and maybe we can talk about it more.

Anyways I think the Project Management lesson kind of deals with all the concerns here about Ruby LSP setup. We definitely don't want to deal with Solargraph (especially because now, RubLSP has overtaken it in feature breadth), and I think the lesson sufficiently covers what's happening with bundler and its artifacts (Gemfile and Gemfile.lock)