v1.0.3 breaks when Sentry (or other packages) wrap the view engine

[fabianclain]

Describe the bug

In v1.0.3, BlazeServiceProvider::registerBlazeRuntime() checks $view->getEngine() instanceof CompilerEngine before injecting the $__blaze runtime variable. When Sentry Laravel (sentry/sentry-laravel) is installed, it decorates the view engine with Sentry\Laravel\Tracing\ViewEngineDecorator, which is not an instance of CompilerEngine. This causes $__blaze to never be injected, resulting in Undefined variable $__blaze errors on all views that render Blaze-compiled components.

This worked in v1.0.2 where the instanceof guard did not exist (or handled decorated engines).

Component causing the issue

Any anonymous Blade component optimized by Blaze triggers the error. For example:

{{-- resources/views/components/smm-navigation.blade.php --}}
@props(['active-tab' => 'facebook'])

{{-- navigation content --}} Used in a parent view:

{{-- resources/views/dashboard/social_media_management/index.blade.php --}}

Expected behavior

The $__blaze runtime variable should be injected into all Blade views regardless of whether the view engine is wrapped by a decorator (Sentry, Debugbar, etc.), and Blaze-compiled components should render normally.

Actual behavior

All views that use Blaze-compiled components throw:

ErrorException: Undefined variable $__blaze in storage/framework/views/94bfea3ca184e60b57992ddfe304b22f.php:127
The compiled view references $__blaze->ensureCompiled(...) but the variable is never set because the engine check fails.

Root cause

In BlazeServiceProvider.php:56-65:

View::composer('*', function (\Illuminate\View\View $view) {
if (Blaze::isDisabled() && ! Blaze::isDebugging()) {
return;
}

if ($view->getEngine() instanceof CompilerEngine) {  // <-- fails here
    $view->with('__blaze', $this->app->make(BlazeRuntime::class));
}

});
$view->getEngine() returns Sentry\Laravel\Tracing\ViewEngineDecorator instead of Illuminate\View\Engines\CompilerEngine, so the instanceof check is false and $__blaze is never injected.

Suggested fix

Unwrap decorated engines before checking, e.g.:

$engine = $view->getEngine();

// Unwrap decorated engines (Sentry, Debugbar, etc.)
while (! $engine instanceof CompilerEngine && method_exists($engine, 'getEngine')) {
$engine = $engine->getEngine();
}

if ($engine instanceof CompilerEngine) {
$view->with('__blaze', $this->app->make(BlazeRuntime::class));
}
Environment

Laravel version: 12.x
PHP version: 8.3
Blaze version: 1.0.3 (works in 1.0.2)
Sentry Laravel: sentry/sentry-laravel (latest)
Additional context

This likely affects any package that decorates the view engine (Sentry, Laravel Debugbar, etc.). The issue is specific to v1.0.3 — pinning to v1.0.2 resolves the problem. Clearing view cache (php artisan view:clear) does not help since the compiled views are regenerated with $__blaze references (Blaze compilation runs fine), but the runtime injection is blocked by the engine check.

[prateekbhujel]

Thanks for the clear report. I was able to reproduce this against v1.0.3.

Root cause was the strict instanceof CompilerEngine check against the top-level engine object. When the blade engine is wrapped by a decorator (for example Sentry's view engine decorator), that check fails and __blaze is not injected.

I opened a fix PR that unwraps decorated engines via getEngine() until a CompilerEngine is found, with cycle protection and a regression integration test:

• test added: injects blaze runtime when blade engine is decorated
• full test suite passes locally

PR: #94

[fabianclain]

thanks for the fix!

[prateekbhujel]

@fabianclain Thanks for checking this my PR was closed because that approach was hacky and #95 is the cleaner fix

[ganyicz]

#95 is related to a previous issue with Sentry but doesn't fix this one specifically.

I'll address this in a separate PR.

Thanks for reporting @fabianclain !

[SimonBarrettACT]

We're seeing the same issue in production with Flare (spatie/laravel-flare) wrapping the view engine.

Symptoms: Nginx 500 (not Laravel 500) on all routes. The Laravel log shows:

Call to undefined function _07477cbe5350e9132c49eb444566a139()
(View: resources/views/layouts/app.blade.php)

The error presents as "undefined function" rather than "undefined variable $__blaze" because PHP hits the function call inside the compiled Blaze output before surfacing the variable error cleanly. This made it harder to diagnose — we initially investigated path hash mismatches, view:cache interactions, and symlink resolution before landing here.

Environment:

• Laravel 12, PHP 8.4, Blaze v1.0.3
• Flux Pro v2 (571 stubs with @blaze directives)
• Flare (spatie/laravel-flare) active in production
• Deployed via Laravel Forge (zero-downtime)

Workaround: BLAZE_ENABLED=false in production .env.

Confirming that the instanceof CompilerEngine guard in registerBlazeRuntime() is the root cause — Flare's engine decorator fails the check, so $__blaze is never injected.

[fabianclain]

@SimonBarrettACT a good fix for now would be to revert to 1.0.2. there is a fix, but not yet merged.

[ganyicz]

@fabianclain @SimonBarrettACT @prateekbhujel

thanks for reporting!

This will be fixed in next release