Running tfsprout¶
tfsprout and tfsproutx work identically; only the registered check set differs. Everything below applies to both.
Analyzing a provider¶
Change into the provider's directory and pass a package pattern:
./... recurses through every package in the module. A bare tfsprout with no package argument prints usage and exits 1 — unlike some linters, there is no implicit default.
To analyze a subtree, which is much faster on large providers:
Findings are printed to stderr in go vet format, and the process exits 3 if anything was reported:
Discovering checks¶
List every registered check:
Read the full documentation for one check, including any flags it accepts:
This is the authoritative description. The check index mirrors it with worked examples of flagged and passing code.
Selecting checks¶
Run only specific checks. Naming any check disables all the others:
This is the practical way to adopt tfsprout on a provider that has never been linted — start with the checks you already pass and grow the list.
Run everything except specific checks. Set them to false:
Do not mix the two styles in one invocation; pick whichever expresses your intent.
Configure an individual check. Per-check flags are namespaced with a dot:
Test files¶
Test files are analyzed by default. Since the AT checks only match inside _test.go files, disabling them silences that entire category:
Applying fixes¶
Only three checks can rewrite code, and -fix edits files in place without a backup. Preview first with -diff, and read Automated fixes before running it.
Running via go vet¶
tfsprout can act as a go vet tool:
In this mode go vet handles package loading and build configuration. Use it when you need build tags, which the binary cannot set on its own:
Suppressing individual findings¶
Add a //lintignore: comment naming the check ID:
See Ignoring reports for scoping rules and adoption strategy.
Machine-readable output¶
JSON goes to stdout, and the exit code is always 0 — a CI job using -json must inspect the output rather than the exit status.
See also¶
- CLI reference — every flag
- CI integration — wiring this into a pipeline
- Troubleshooting — when something looks wrong