Unify Fantomas versions across editors.

[nojaf]

I propose we find a way to use the same version of Fantomas in all major editors.
The main idea would be that a pinned fantomas-tool version can be used by the editor.

The existing way of Fantomas deals with this problem is quite a messy story. There used to be three approaches:

• FsAutocomplete used a compatible version on NuGet.
• Rider had a fork of Fantomas (this will no longer be the case in the upcoming 2021.2 release).
• Visual Studio uses a specific commit via git submodules.

In short, in a lot of scenarios you need to fall back to formatting using the command-line to be in control of the version of Fantomas. This is a necessary evil when using the --check flag in CI builds or when the developers use multiple editors.

Pros and Cons

The advantages of making this adjustment to Fantomas are:

• Reducing the impact of new Fantomas releases. If a new release drops, each party now has work to do to cope with this.
• The end-users can be in control of the exact version of Fantomas. Users can move to newer versions at their own pace.
• Fantomas could potentially use prerelease FCS NuGet packages as the hard stable FCS dependency would be dropped.

The disadvantages of making this adjustment to Fantomas are:

• Fantomas would rely on its own FSharpChecker instance and will no longer re-use existing AST nodes that are often already present in the editor tooling.
• A very stable mechanism will be required to keep the integration working for all future Fantomas versions to come.

Implementation

I propose that we introduce a new NuGet package called Fantomas.Client. This will find a compatible fantomas-tool version in the current working directory, spin up a new process of fantomas-tool and communicate via a custom LSP protocol.

To make this work, we should extend fantomas-tool with a --daemon flag. When running in daemon mode, stdio is being used to communicate with Fantomas.Client. Messages are being sent back and forth and the formatting happens outside-of-process for the editor tooling. A single FSharpChecker is being used for the entire lifecycle of the daemon process.

The FantomasService interface exposed in Fantomas.Client should have the following capabilities:

• FormatDocument
• FormatRange
• GetConfigurationOptions (as these tend to change between versions)

The format endpoint should respect existing behaviour:

• Get the configuration via .editorconfig or passed down explicitly (in a loose structure).
• Respect ignore files.
• Implementation file versus signature file.

Extra information

Estimated cost (XS, S, M, L, XL, XXL): L or XL.

I've already started out with an experimental version in my ras-al-ghul branch. Hence, the reason why some of the implementation details are already known. Check out DaemonTests to get a sense of the usage from an editor point of view.
There is still much work to be done and I wanted to give some potential stakeholders a heads-up and the possibility to discuss this feature. Don't worry, this will take a lot of time, alpha's and beta's before it ships.

I'm also strongly considering supporting two versions of Fantomas going forward. The master branch would be used for bug fixes and new revisions can be published from there. The new feature would be implemented in a 4.6 branch that would be in sync master and produce alphas and betas.

Tagging some people: @deviousasti, @baronfel, @Krzysztof-Cieslak, @auduchinok, @DedSec256, @Smaug123, @stackedsax, @c-rindi , @jgiannuzzi and @jindraivanek.

Let me know your thoughts! I for one think we are on to something here 😊.

Affidavit (please submit!)

Please tick this by placing a cross in the box:

• I have read the Contribution Guidelines.
• I have searched both open and closed suggestions on this site and believe this is not a duplicate

Please tick all that apply:

• This is not a breaking change to Fantomas
• I or my company would be willing to help implement and/or test this
• This suggestion is part of the Microsoft style guide (please add a link to section if so)
• This suggestion is part of the G-Research style guide (please add a link to section if so)

[baronfel]

It would be lovely to have project-defined versions of fantomas (perhaps in the .net tools config) and be able to transparently use those. Absolutely in favor of this, any (mild) perf overhead from being out-of-process is IMO vastly outweighed by the stability of having the user control the versions, and the stability of not tying FSAC and other editors to Fantomas' version of FCS (and vice-versa).

[deviousasti]

I second this proposal.

• There was a similar discussion over here: Q: Ensuring same fantomas version with fantomas-tool and extension fantomas-for-vs#12
• I have implemented a out-of-process server for my fsharp-worksheet. (https://github.com/deviousasti/fsharp-worksheet/blob/master/server/JsonRpc.fs). The StreamJsonRpc library is maintained by the Visual Studio team.
• The configuration options would need to be serializable

[auduchinok]

We already use a similar out-of-process Fantomas daemon approach in Rider 2021.2, and it indeed simplifies maintenance a lot and allows us to easily use Fantomas package from Nuget instead of the fork we used to have.

[nojaf]

Available in 4.6