FSharp.Refactor

FSharp.Refactor

Let's remove parentheses from the internet

Functional refactoring suggestions for F#. The tool clarifies the (agent-generated or old) code's intent, reduces non-alphanumeric noise, and uses built-in .NET libraries more efficiently.

• light bulb quick fixes in your editor
• command-line tool that applies them in bulk.

Suggestions are Hint severity: they mark an opportunity, not a defect, and never gate your build.

This project is the big brother of CSharp.Refactor

---

Using it

The tool is fully offline: AI has been used to make it, but it doesn't use AI.

Quick start

Nothing to configure - the tool reads your project, reports what it would change, and only edits when you tell it to:

dotnet tool install --global fsharp-refactor

fsharp-refactor Your.fsproj --dry-run --api-changes

That prints every fix it would make, with file and position, and writes nothing. When the list looks right, drop the flag to apply them:

fsharp-refactor Your.fsproj --api-changes

It refuses a compilation that does not already build, and fails loudly if applying ever introduces an error.

If you don't want change public methods / API, drop --api-changes:

fsharp-refactor Your.fsproj

For light bulbs while you type, see VS Code / Ionide and Visual Studio IDE-plugin instructions below.

For agentic scenarios the dotnet tool supports MCP.

Using the tool: Point it at whatever you have - the kind is read off the path:

What it changes

Examples:

A spread of what the 150-odd rules do - the full list is in Refactorings:

Editor and CI setup

The analyzers ship as FSharp.Refactor.Analyzers. The package is a development dependency: it only produces hints and quick fixes - nothing from it flows into your compiled output.

NOTE: EVEN WHEN ADDING A NUGET REFERENCE, THIS ANALYSER WILL NOT COME TO OUTPUT PATH (BIN) AND WILL NOT BE PART OF YOUR PROJECT.

VS Code / Ionide

Easiest: install the FSharp.Refactor VS Code extension

• it bundles the analyzers and (with your consent) wires them into

Ionide's settings globally, so every F# project gets the hints with no per-project setup.

Or wire a single project by hand: reference the package from the project you want analyzed:

<PackageReference Include="FSharp.Refactor.Analyzers" Version="*" PrivateAssets="all" />

then point Ionide at the restored analyzers in .vscode/settings.json:

{

"FSharp.enableAnalyzers": true, "FSharp.analyzersPath": [ "~/.nuget/packages/fsharp.refactor.analyzers/ /analyzers/dotnet/fs" ] }

replacing with the version restore actually picked (the NuGet cache always keys folders by version, so this one path cannot float; check with ls ~/.nuget/packages/fsharp.refactor.analyzers/). On Windows the cache lives under %USERPROFILE%\.nuget\packages. Suggestions appear as Hint-severity diagnostics with a light-bulb one-click fix.

FsAutoComplete 0.85+ titles each fix by what it writes (Fix FR0136 → Guid.NewGuid()); an older one says only Fix FR0136. Ionide bundles its own FsAutoComplete; to run a newer one, dotnet tool install -g fsautocomplete and set FSharp.fsac.netCoreDllPath to its fsautocomplete.dll (the extension above offers to do both).

The package ships the analyzers built against TWO FSharp.Analyzers.SDK versions side by side - FSharp.Refactor.Analyzers.Ionide.dll for SDK 0.35.0 (what stock Ionide's FsAutoComplete bundles, 7.31.x and earlier) and FSharp.Refactor.Analyzers.dll for SDK 0.37.2 (the CLI, and FsAutoComplete 0.84+). The SDK loads only the assembly matching its own version and logs a skip line for the other, so every host picks the one it can use and no configuration choice is needed.

If no suggestions appear, open Output -> "F# Language Service": it names the analyzer dlls it scanned and how many analyzers loaded, and a version-pairing skip is spelt out there rather than surfacing in the editor.

Visual Studio 2022-2026

Install the FSharp.Refactor Visual Studio extension (user-facing overview): squiggles and Ctrl+. quick fixes in full Visual Studio, analyzed through an FsAutoComplete sidecar. One prerequisite: dotnet tool install -g fsautocomplete.

CLI / CI

dotnet tool install --global fsharp-analyzers

fsharp-analyzers --project src/YourProject.fsproj --analyzers-path ~/.nuget/packages/fsharp.refactor.analyzers/ /analyzers/dotnet/fs --code-root . --report analysis.sarif

fsharp-analyzers is the analyzer HOST, and it is the dotnet tool you install. This package is not a tool: it is a library of analyzer assemblies the host loads, so it is passed as a directory rather than installed. That directory sits in the NuGet cache because an analyzer package deliberately has no lib/ folder and is marked a development dependency - a PackageReference therefore puts nothing in your bin, and after a restore, the cache is where the assemblies live. --analyzers-path takes any folder holding them and searches it recursively.

The CLI only REPORTS; it never edits your files, which is what you want in CI (SARIF output works in GitHub code scanning). To apply the fixes, use our own tool below. Individual rules can be turned off per repository with a fsharprefactor.json - see Configuration below.

Applying fixes from the command line

The fsharp-refactor dotnet tool applies the quick fixes directly to your files:

dotnet tool install --global fsharp-refactor

fsharp-refactor Your.fsproj [--dry-run] [--codes FR0002,FR0031] [--api-changes] [--jobs 4] [--max-passes 5]

(or from this repository: dotnet run --project src/FSharp.Refactor.Tool -c Release -- Your.fsproj ...)

For a project it takes the exact compiler arguments from MSBuild; for a script FCS resolves the references itself and MSBuild never runs. Either way it then runs every analyzer, applies non-overlapping fixes bottom-up, and re-analyzes until a pass applies nothing - a fix can enable further fixes. It refuses a compilation that already has errors, and fails loudly if applying ever introduces one.

Warnings as errors: the project's own settings decide, and the tool never overrides them - its verification is the build your CI runs. The in-memory typecheck takes the compiler's own arguments, so --warnaserror and turn an F# warning a fix raises into an error the pass rolls back. A C# project that references the F# one and turns an analyzer warning into an error (error CA1859, error IDE0005) fails the verification build as code, not as tooling noise, and the run says which setting to change if you want such fixes anyway ( CA1859 , or dotnet_diagnostic.CA1859.severity = suggestion). works too, but silences the analyzer for everyone.

| --notes [on|off|only] | --notes (or --notes on) lists fix-less advisory notes inline; --notes only is the review pass described next. By default a run prints its FIXES - the product - and ends with one per-category note count (41 advisory note(s) held: …); SARIF (--report) and --format json