What's the story for breaking changes in FCS when using FSharp.Analyzers.SDK?

[cmeeren]

If I write an analyzer using FSharp.Analyzers.SDK, is it possible to run this analyzer when Ionide is updated to use new versions of FSharp.Analyzers.SDK (which may use a new version of FCS with binary breaking changes)? Or will I need to always keep my analyzer up-to-date with the latest version of this SDK, in order for it to be usable in new versions of Ionide?

[TheAngryByrd]

Unfortunately, in my experience it’s the latter. I’d definitely like to discuss and Explore options on how to make this less brittle.

[cmeeren]

Related: RFC, discussion

[cmeeren]

I think the best solution is for Ionide to consider integrating with FSharp.Analyzers.SDK similarly to how Rider does Fantomas integration:

Rider comes bundled with a version of Fantomas, but will by default use a locally or globally installed Fantomas version, in that order. This means that it will work "out of the box", but users can override the version by installing Fantomas as a dotnet tool.

In terms of FSharp.Analysers.SDK: You could bundle one version with Ionide, but auto-detect (and allow explicit override from) a locally or globally installed version. Then, if the user has problems with binary incompatibility between the SDK and an analyzer, they can pin the version of the SDK as a dotnet tool to ensure stable functionality. They can then update whenever they want, e.g. when the analysers they use have been updated.

[cmeeren]

A related concern: What happens if analyzing a file with a new F# syntax that is not supported by the FCS version used by FSharp.Analyzers.SDK? Does that mean that all analyzers using FSharp.Analyzers.SDK will fail on that file, and will not be able to be updated to support it until the SDK has first been updated? If so, can the SDK be expected to be updated in a timely manner, or is this a process that (regardless of the reason) could take, say, many weeks or months?

Not judging in any way, just trying to figure out whether or not this SDK is the right fit for the linter I'm experimenting with. Being blocked from adding timely support for new F# versions could be a show-stopper.

[baronfel]

Yep, this cascading behavior your describe accurately captures the current situation. It's mitigated somewhat because only Ionide supports analyzers, but you could imagine that if analyzers were in the compiler we'd start hitting this all the time.

The problem is the DU-based nature of the API, sadly. We need better strategies around handling DU changes across versions.

[cmeeren]

I see. If there is new F# syntax so that FSharp.Analyzers.SDK needs to be updated before analyzers can work on files using that new syntax, can the SDK be expected to be updated in a timely manner, or is this a process that (regardless of the reason) could take, say, many weeks or months?

If it could take a long time, I think that the SDK is not at the moment the right fit for the linter I'm making. A linter is an important tool that people may depend on in their CI setups, and if it is blocking them from using new F# features for weeks or months, that would not be acceptable to many.