Use globally installed gems for formatter

[sevenc-nanashi]

I have checked that this feature is not already implemented

• This feature does not exist

Use case

Currently, formatter does not work when bundler is not configured. This is inconvenient when writing ruby as one-time script.

Description

Allow using globally installed formatter gem as a formatter.

Implementation

No response

[vinistock]

Thanks for the suggestion. I have a few questions about how this could be handled with good developer experience.

1. How do we decide which formatter to use? And what version do we require? Imagine someone has several installations of rubocop, standard and syntax_tree in their machine. How will we know which one to pick? Someone could propose using the rubyLsp.formatter setting, but then that means you would need to manually pick a formatter when working on scripts and then manually revert back to auto for automatic formatter selection. It's not a great experience overall
2. How do we know that the user indeed wants random files to be formatted? In the beginning of the Ruby LSP, we use to do exactly this. We had syntax_tree as a dependency and always formatted any files using it unless another formatter was a part of the bundle. The majority of the feedback we received was that this was not a good experience because most people didn't expect their files to get formatted when there was no bundle or formatter included

The key concern is that without some signal (in this case, a formatter included in the project's bundle) it's really difficult to predict what the user wants.

One option we could try is adding a new setting. Something like rubyLsp.globalFormatter. If that's set to a formatter, then the LSP attempts to require whatever version of that is installed when there's no bundle.

Do you have any other ideas?

[sevenc-nanashi]

The majority of the feedback we received was that this was not a good experience because most people didn't expect their files to get formatted when there was no bundle or formatter included

Ah I didn't know that...

I think having global formatter option is a good way because it can be not only formatter specification but also intention to have global formatter.

[vinistock]

After an internal discussion, the team ended up agreeing to not add this for now. There's considerable potential for edge cases and confusing behaviour even if we add the setting for the global formatter.

Here are some examples of the concerns:

• If you're using the global formatter, what configurations should it use? There's no .rubocop.yml file or equivalent. However, people are very opinionated about how they want their code formatted, so this would probably lead to asking us to support passing configurations to the global formatter through yet another extension setting
• What happens if the global formatter is not installed for the Ruby version currently activated? Do we error and let the user fix the issue? Do we auto install it?
• When you simply require "some_formatter", RubyGems will pick the latest version. What if there are breaking changes in the formatter that aren't yet compatible with the LSP? In that case, I could then see someone proposing adding version constraints to the setting so that we can avoid this situation. Before we know it, we're building a simplified version of Bundler checks to account for versioning

Overall, there's a lot of potential for error scenarios that aren't super trivial to handle and deliver a good experience. Considering that you can get formatting by just adding a Gemfile with two lines, we agreed to encourage that approach instead.

E.g.:

# This is enough to get formatting and you can add the formatter's configuration
# file at the same level
source "https://rubygems.org"
gem "rubocop" # or any formatter

Thanks for proposing this!