BladeCompileError
Emitted on line 1 of a Blade template that failed to compile (the Blade compiler or the plugin’s own declaration parser threw). The template is skipped, and the message reads Template not analyzed: <cause>, where the cause is the compiler’s own message on one line. Needs Blade template analysis enabled.
A skipped template loses every finding it would have produced, and a template that used to report issues and now fails to compile would otherwise look like an improvement. The issue is therefore an error: it fails the run, survives --no-progress, shows up in every --output-format, and is recorded by --set-baseline.
Common causes
- Prose that Blade reads as a directive (
@component,@section) without arguments. Escape it as@@component. - A malformed directive, such as
@foreachwithoutas. - A directive, condition, or precompiler callback that throws when called outside a request.
- A component tag (
<x-...>) whose class or view cannot be resolved by the booted application (see Known limits). - The plugin’s own declaration parser crashed on the template. This is a plugin bug: report it with the template.
The line is always 1: the compiler reports no template line.
How to fix
Fix the template, or make the failing directive or component resolvable in the booted application. When the failure is expected (the directive genuinely needs a request), suppress the issue for that template:
<issueHandlers>
<PluginIssue name="BladeCompileError">
<errorLevel type="suppress">
<file name="resources/views/dashboard.blade.php" />
</errorLevel>
</PluginIssue>
</issueHandlers>
A `` comment in the template cannot silence it: that comment only takes effect in the compiled template, and this template never compiled.
Limitations
- Not reported when Blade analysis turned itself off for the run (see Degradation). The run-level warning covers every template instead.
- A template that cannot be read, or whose compiled shadow cannot be written, is not a compile failure. It stays in the run-level warning.