Automated fixes¶

Both commands accept a -fix flag, which applies suggested fixes in place:

tfsprout -fix ./...

Set your expectations low. tfsprout is overwhelmingly a reporting tool. Of the checks that ship today, only three produce a suggested fix, and two of those are extra checks that are not enabled by default.

Checks that support -fix¶

Every other check reports only. Running tfsprout -fix on a provider with hundreds of findings will change almost nothing, and that is expected behavior rather than a failure.

In practice this means:

• tfsprout -fix ./... can only ever modify code that uses the deprecated Partial API.
• tfsproutx -fix ./... additionally removes os/exec calls, which is a deliberately aggressive rewrite — read XR007 and XR008 before running it.

How fixes are produced¶

Fixes come from the SuggestedFixes field of a go/analysis diagnostic, and are generated by the shared runners in helper/analysisutils/runners.go rather than by individual checks. Only analyzers built on the deprecation and avoidance runners — DeprecatedReceiverMethodSelectorExprAnalyzer and AvoidSelectorExprAnalyzer — carry them.

This is why fix support tracks the shape of a check rather than its usefulness: a check that says "replace this call with that call" can express a fix mechanically, while a check that says "this schema is contradictory" cannot know which field you meant to keep.

Before you run it¶

-fix edits your files in place. It does not create a backup and it does not ask.

git status --porcelain   # confirm a clean tree
tfsprout -fix ./...
git diff                 # review every change

Always review the diff. Suggested fixes are textual rewrites produced without knowledge of your intent, and they are not covered by your test suite until you run it.

Adding fix support to a check¶

If you are writing a new analyzer and want it to support -fix, attach SuggestedFixes to the diagnostic and add golden-file tests. See Testing for the analysistest.RunWithSuggestedFixes workflow.