Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Severity Levels

Every rule has a severity: error or warning. All rules default to error.

Effect on exit code

SeverityReportedAffects exit code
errorYesYes — exit 1 if any errors exist
warningYesNo — exit 0 even if warnings exist

This lets teams adopt rules incrementally: configure new rules as warning during a rollout period, then promote them to error once the codebase is clean.

Configuring severity

Override per rule in squint.toml:

[rules.severity]
LT05 = "warning"   # long lines are warnings
CP02 = "warning"   # identifier casing is a warning during rollout
CP01 = "error"     # keyword casing is always an error

Only rules you want to change need to appear here. All others remain at their default (error).

Text output

Severity is shown in brackets before the rule ID:

models/stg_orders.sql:3:1: [error] [CP01] Expected lowercase keyword, got 'SELECT'
models/stg_orders.sql:5:45: [warning] [LT05] Line too long (143 > 120 characters)

The summary line distinguishes errors from warnings:

Found 1 error and 1 warning in 1 file.

JSON output

The severity field is included per violation:

{
  "line": 3,
  "col": 1,
  "rule_id": "CP01",
  "message": "Expected lowercase keyword, got 'SELECT'",
  "severity": "error"
}

LSP diagnostics

The LSP server maps errorDiagnosticSeverity::ERROR and warningDiagnosticSeverity::WARNING, so your editor shows them with the appropriate indicators (red vs yellow underlines in most themes).