Allow for saving arguments in a config file

[baronfel]

Fantomas should allow for inputting formatting arguments via a config file, like .fantomas-config. This config file could be located by convention or by an explicit CLI flag. Having such a file would allow for settings to be tracked in source control, applied without the user having to remember many cli flags, and make it easier to run formatting via shell utilities, FAKE, various editor toolings, etc.

[nojaf]

This seems like a good idea but I personally don't have any aspirations of pursuing this.
When I'm using cli I have a bat file that wraps my preferred options:

ff.bat:
fantomas --preserveEOL --reorderOpenDeclaration --force %*

So when I format from a prompt I do ff myFile.fs.

As for editors, both Rider and vscode have a settings section already available.
And FAKE can use the FormatConfig record itself.

So I'm not entirely convinced that we should introduce a .fantomas-config file.

[prosconi]

@nojaf do we want to do this or not? If so, I wouldn't mind submitting a PR to get my feet wet into the repo

[nojaf]

@prosconi I would like to see a more fleshed out suggested approach for this feature first.
What file format do you have in mind? Where would the config file reside? Project-level? User folder?

[prosconi]

I was thinking the format would be JSON. As far as where the file lives, that is a tricky one since there are a lot of ways to invoke fantomas

• CLI Explicit -> Look for command line parameter
• CLI Folder -> Look for inputPath\.fantomas-config
• CLI File -> Look for Path.GetDirectoryName(inputPath)\.fantomas-config
• CLI StdIn -> ???
• API -> Require user to load config manually?

[jindraivanek]

I am in favor of this.

Agree with format JSON, maybe some auto (de)serializing library will be best. Anyway, it should be fail-safe, missing field in config file should be replaced by default option, and extra field (option that not exist in Fantomas) should not break loading of config (but it should emit some warning on stdout).

Regarding location of config file, I would prefer unified behavior, where config file is applied to whole subdirectory - so we will look for config file in target dir and in all parent dirs.

API should not look for config file, but we could make API for load config from file. AFAIK all API calls take config as explicit parameter.

[MangelMaxime]

Hello,

I saw this issue poping on twitter and read the thread.

Agree with format JSON, maybe some auto (de)serializing library will be best. Anyway, it should be fail-safe, missing field in config file should be replaced by default option, and extra field (option that not exist in Fantomas) should not break loading of config (but it should emit some warning on stdout).

This description looks really similar to what I am doing for Nacara config file where I am using Thoth.Json.

it should be fail-safe, missing field in config file should be replaced by default option

It's easy to map missing field via Option.defaultValue

extra field (option that not exist in Fantomas) should not break loading of config (but it should emit some warning on stdout).

Thoth.Json(.Net) only decode the field you ask it to do. So extra fields are not checked.

type Config =
    { NpmURL : string option
      GithubURL : string option
      Url : string
      BaseUrl : string
      Title : string
      Version : string
      Source : string
      Output : string
      IsDebug : bool
      Changelog : string option
      Navbar : NavbarConfig option
      MenuConfig : MenuConfig option
      LightnerConfig : LightnerConfig option }

    static member Decoder =
        Decode.object (fun get ->
            { NpmURL = get.Optional.Field "npmURL" Decode.string
              GithubURL = get.Optional.Field "githubURL" Decode.string
              Url = get.Required.Field "url" Decode.string
              BaseUrl = get.Required.Field "baseUrl" Decode.string
              Title = get.Required.Field "title" Decode.string
              Version = get.Required.Field "version" Decode.string
              Source = get.Optional.Field "source" Decode.string
                        |> Option.defaultValue "docsrc"
              Output = get.Optional.Field "output" Decode.string
                        |> Option.defaultValue "docs"
              IsDebug = get.Optional.Field "debug" Decode.bool
                        |> Option.defaultValue false
              Changelog = get.Optional.Field "changelog" Decode.string
              Navbar = get.Optional.Field "navbar" NavbarConfig.Decoder
              MenuConfig = get.Optional.Field "menu" menuConfigDecoder
              LightnerConfig = get.Optional.Field "lightner" LightnerConfig.Decoder }
        )

[Krzysztof-Cieslak]

Hey, we would need that for FSAC/Ionide - instead of “polluting” Ionide’s setting with all Fantomas setting and keeping them in sync regarding new options and default settings I’d rather have users use Fantomas specific config file maintained here.

In regards of where to place file I think we may try to replicate FSharpLint behavior (consistency in ecosystem) - read more in Configuration Files section on http://fsprojects.github.io/FSharpLint/

From the API perspective I guess all we’d need is a function that will read config file for given location and return Fantomas’ config object

[nojaf]

I'll take a shot at this during the holidays.
Agreed to add something in the API that reads the configuration similar to FSharplint.

I'm not a fan of using the JSON format as I don't want the dependency to NewtonSoft.Json or anything else.
Proposing a simple format where each setting is on one line, key/value style.

For example: .fantomas-config

PageWidth=90
ReorderOpenDeclaration=True

Maybe logic from Fantomas-UI can be re-used.