Skip to content

Baselines

Terminal window
bonsai-lint --write-baseline src/

Records everything currently above the threshold as accepted. Later runs fail only on scores that got worse, or on units the baseline has never seen. An unknown key is treated as a regression, never as an acceptance. A renamed function is reported rather than silently inheriting someone else’s amnesty.

A baseline also has to tighten, or it rots into a permanent exemption. A scan that covered the whole domain names every entry that rewriting the baseline would drop or lower: a unit that now scores less, one no longer over its threshold, one suppressed with a reason, and one that matched nothing because it was deleted or renamed.

Terminal window
root: src/Checkout.php: Checkout::apply is baselined at 38 but scores 20
root: src/Legacy.php: Legacy::run is baselined at 21 but matched nothing in this scan

Those lines are warnings. With --strict-baseline, or strict-baseline = true, they fail the run, so an improvement has to be locked in: once nothing else fails, rewrite the baseline with --write-baseline over the whole workspace and the run’s other flags. On a subset it would empty the rest of the baseline (roadmap). Raising a threshold, or passing --over above the one the baseline was written with, leaves entries unneeded too. A single file from a pre-commit hook, an editor buffer, --domain or --lang never judges a baseline, since it cannot see the entries whose units are gone.

Without a bonsai-lint.toml, the directory holding the baseline is the project root, so bonsai-lint --write-baseline . followed by bonsai-lint src/Foo.php finds the same entries.