Features

Inline Suppressions

A rule can be right in general and wrong in one spot. Rather than turning it off for the whole project, mark the exception where it is, next to the reason:

{{-- sheath-disable-next-line security-no-raw-echo -- sanitised in the view model --}}
{!! $post->renderedBody !!}

#Syntax

Choose the narrowest comment that covers the intended exception.

Comment Scope
{{-- sheath-disable-next-line --}} The line after the comment
{{-- sheath-disable-line --}} The line the comment sits on
{{-- sheath-disable --}} From the comment to a matching enable, or end of file
{{-- sheath-enable --}} Ends a sheath-disable region
{{-- sheath-disable-file --}} The whole file, wherever the comment appears

HTML comments work identically, which matters in templates that use both:

<!-- sheath-disable-next-line a11y-alt-text -->
<img src="{{ $spacer }}">

The directive name must begin at a token boundary. Prefixes made from letters, digits, _, or - are not directives: nosheath-disable and x-sheath-disable remain ordinary comment text. Punctuation and whitespace may precede a directive.

#Naming Rules

A bare comment suppresses every rule. Name one or more rule IDs, separated by spaces or commas, to suppress only those:

{{-- sheath-disable-next-line a11y-alt-text --}}
{{-- sheath-disable-next-line a11y-alt-text, perf-lazy-load-images --}}

Prefer naming rules. A bare suppression hides findings from rules that did not exist when it was written.

#Explaining Yourself

Anything after a -- separator is ignored, so the comment can carry its reason:

{{-- sheath-disable-next-line security-no-raw-echo -- markdown is escaped upstream --}}
{!! $post->body !!}

Order matters: {{-- sheath-disable-next-line -- rule-name --}} (dashes before the rule) reads as a bare directive followed by a reason, so it suppresses every rule on that line, not just the one named. Put rule names before the -- separator.

#Regions

sheath-disable opens a region that runs until a matching sheath-enable, or to the end of the file if there is none:

{{-- sheath-disable best-practices-no-inline-styles --}}
<div style="{{ $chartStyles }}">...</div>
<div style="{{ $legendStyles }}">...</div>
{{-- sheath-enable best-practices-no-inline-styles --}}

Enabling a single rule inside a blanket disable revives that rule and leaves the rest suppressed, the same way eslint-enable behaves:

{{-- sheath-disable --}}
{{-- sheath-enable a11y-alt-text --}} {{-- alt text is still enforced here --}}

A disable whose rule list contains no valid names suppresses nothing. An enable whose list contains no valid names re-enables everything instead of matching nothing, so a preceding blanket disable cannot stay open past a typo. Both directions fail toward reporting.

#Suppressed Findings Are Not Fixed

A suppressed violation is removed before fixes are collected, so --fix will not rewrite the line either. That makes a suppression comment the way to protect a line from autofix at a single site, where neverFix disables a rule's fixes project-wide.

#Turning Suppressions Off

For a CI or audit run that must report suppressed findings, ignore every suppression comment:

php artisan sheath:lint --no-inline-config

Or permanently, in config/sheath.php:

'inlineSuppressions' => false,

It matters most for security rules: a suppression comment is invisible in a diff unless someone is looking for it.

#Choosing a Suppression

Match the suppression scope to the smallest affected region.

Need Prefer
One legitimate exception on one line sheath-disable-next-line naming the rule
A block of related exceptions sheath-disable / sheath-enable naming the rule
A whole generated or vendored template An ignore pattern
Keep reporting, but never autofix neverFix
Lower urgency without hiding the finding Severity warning or info
Adopting on an existing codebase A baseline
Debugging one rule or area --only, or explicit paths
A parser edge case The narrowest ignore pattern, plus a bug report

#See Also