Specifically handle the case where bin/rails is not found

[st0012]

When the file is not found, it is likely that the LSP is not being run in the root of a Rails project. Having a more specific error message will help the user understand what is going on.

[andyw8]

I was working on this approach in ruby-lsp, so that if the app doesn't have bin/rails then we don't install the addon: Shopify/ruby-lsp#1467.

[vinistock]

In regards to installing the addon or not, at the root of it is the question "is there value in having this addon even if it's not a Rails app?".

I think the answer might be yes because of the code lens support for Active Support style tests. But I'm not 100% sure to be honest. Thoughts?

[vinistock]

This will fail in workspace that are symlinks, since the addons don't yet have access to the workspace URI announced by the editor. There's nothing to do now, but I wanted to document this.

We need to create some sort of State object in the Ruby LSP that addons get initialized with, containing all of the initialization options, the message queue, etc.

[st0012]

I think the answer might be yes because of the code lens support for Active Support style tests. But I'm not 100% sure to be honest. Thoughts?

In addition to those, once we implemented something like go-to-definition to DSL symbols, like

before_save :foo # cmd+click :foo jumps to foo method

Then it'll be useful in Rails engine development too.
And if we decided to support customising test code lens' executable name (e.g. bin/test instead of bin/rails test), it can directly benefit rails/rails and Rails engine devs too.

[andyw8]

In regards to installing the addon or not, at the root of it is the question "is there value in having this addon even if it's not a Rails app?".

I think the answer might be yes because of the code lens support for Active Support style tests. But I'm not 100% sure to be honest. Thoughts?

One confusing aspect is that you'd always end up ruby-lsp-rails in .ruby-lsp/Gemfile even for a plain Rails app that doesn't use Active Support tests.

Perhaps we can treat rails/rails as a special case and install ruby-lsp-rails, and for other repos have some option in the upcoming .ruby-lsp.yml to opt in?

[vinistock]

Perhaps we can treat rails/rails as a special case and install ruby-lsp-rails, and for other repos have some option in the upcoming .ruby-lsp.yml to opt in?

I feel like it might be early to make that decision. IMO, we can go with this PR and make a decision once we have more context.

[andyw8]

Being removed in #285

[andyw8]

Interesting, got a failure CI because on Ubuntu the error looks like:

Ruby LSP Rails booting server\nRuby LSP Rails failed to initialize server: bin/rails: 1: foo: not found
but on other platforms:
Ruby LSP Rails booting server\nRuby LSP Rails failed to initialize server: bin/rails: line 1: foo: not found