Allow rubyfmt to be part of the "auto" formatter option

[keshavbiswa]

I have checked that this feature is not already implemented

• [x] This feature does not exist

Use case

Setting formatter: "auto" should check for add ons as well, if "ruby-lsp-rubyfmt" is available it should allow to fallback to rubyfmt instead of setting formatter to "none".

This is helpful in scenarios when we have to deal with multiple codebases with multiple code linting tools.

Description

I work with multiple codebases using different linters, rubyfmt, rubocop, etc. I can't set my formatter to "rubocop" or "auto", because I need "rubyfmt" for some.

The only workaround for me is to constantly change my formatter everytime I work on a different codebase.

It seems, "auto" only supports "rubocop" and "syntax trees" as these are Lsp Supported.

I propose to allow add-ons to be part of "auto" if it exists in the workspace.

Implementation

I did a quick tour of the codebase and I'm assuming while setting global state for the formatter we need to detect add-ons formatters too:

    def detect_formatter(direct_dependencies, all_dependencies)
      # NOTE: Intentionally no $ at end, since we want to match rubocop-shopify, etc.
      return "rubocop_internal" if direct_dependencies.any?(/^rubocop/)

      syntax_tree_is_direct_dependency = direct_dependencies.include?("syntax_tree")
      return "syntax_tree" if syntax_tree_is_direct_dependency

      rubocop_is_transitive_dependency = all_dependencies.include?("rubocop")
      return "rubocop_internal" if dot_rubocop_yml_present && rubocop_is_transitive_dependency

      "none"
    end

If it's accepted I can add the logic to detect add on dependencies

[keshavbiswa]

Here's some more context:

When formatter is set to "rubocop" and rubocop doesn't exist in the Gemfile but "ruby-lsp-rubyfmt" does:

Notice the formatter is set to "rubocop_internal"

[{"response":{"data":{"__data__":"vim-lsp","init_result":{"id":1,"result":{"formatter":"rubocop_internal","capabilities":{:{},"documentFormattingProvider":true,"documentSymbolProvider":{},"experimental":{"addon_detection":true,"compose_bundle":true },"message":"lsp server already initialized"}}]

When the formatter is set to "auto" in the same codebase where ruby-lsp-rubyfmt exists:

The formatter goes to "none"

[{"response":{"data":{"__data__":"vim-lsp","init_result":{"id":1,"result":{"formatter":"none","capabilities":{},"documentLinkProvider":{},"documentOnTypeFormattingProvider":{"moreTriggerCharacter":["\n","|","d"],"firstTriggerCharacter":"{","documentSelector":null},"definitionProvider":true,"documentRangeFormattingProvider":true,"semanticTokensProvider":{"legend":{"tokenTypes"]

[vinistock]

Thank you for the report. Part of the reason why we started allowing formatters and linters to integrated with the Ruby LSP through our add-on API was so that we didn't have to maintain logic for each different tool.

Currently, the auto-detection is breaking that since we have formatter specific logic in there. The right fix for this would be to first introduce a new add-on API for auto-detecting if a formatter should be activated, so that we can put the responsibility on the formatters themselves to identify if they should be used.

Then we need to migrate our internal integrations for RuboCop and Syntax Tree to use that new API, getting rid of the current detection logic, which would finally allow for other formatters to auto-detect.

[github-actions[bot]]

This issue is being marked as stale because there was no activity in the last 2 months

[github-actions[bot]]

This issue is being marked as stale because there was no activity in the last 2 months