Allow specifying scalafmt config choices

[keynmol]

Is your feature request related to a problem? Please describe.

Currently Metals suggests creating Scalafmt config on first issue of the formatting request.

By default, it adds a very unopinionated config (e.g. here for Scala 3 project):

version = "3.7.14"
runner.dialect = scala3

While convenient, this is quite limited.

For example, in pretty much all of my project I use the same Scalafmt config starter:

runner.dialect = scala3
rewrite.scala3.insertEndMarkerMinLines = 10
rewrite.scala3.removeOptionalBraces = true
rewrite.scala3.convertToNewSyntax = true

Other people might have different options. On a normal week I create dozens of throwaway Scala scripts and worksheet sessions, where I'd want to have consistent formatting (well, consistent according to my tastes, of course, everyone is different).

FR: I would like the ability to customise the scalafmt config that Metals creates

Describe the solution you'd like

I propose having a configuration setting that Metals accepts, which creates a named list of Scalafmt config options:

{
  "metals": {
    "scalafmtTemplates": {
      "scala3": {
         "options": "runner.dialect = scala3\nrewrite.scala3.insertEndMarkerMinLines = 10\nrewrite.scala3.removeOptionalBraces = true",
         "defaultForScala3": true
      },
      "scala2-cross-bla": {...}
    }
  }
}

• The names of configs are user-defined, they don't indicate any connection to the Scala version
• If config is specified, options field is requied
• version field is optional, and defaults to current latest that Metals can identify
• defaultForScala3 and defaultForScala2 fields are optional and only 1 config can be marked so
• In the absence of this config or if the scalafmtTemplates is empty, default to current Metals behaviour
• If the config is non-empty, offer user a choice of which file to create
• If there's only 1 Scala version in the project, and there exists a config with defaultForScala* property set to true, create .scalafmt.conf without asking the user, then run the formatting request
• If the template contains version field, it's preserved
• If the template doesn't contain version field, it gets added with latest Scalafmt version Metals knows about

Describe alternatives you've considered

Manual management of Scalafmt configs, but this is quite cumbersome. I believe silently creating scalafmt config if the user explicitly configured their Metals is a good UX.

Additional context

No response

Search terms

scalafmt, metals, config