String Blade Compiler Laravel Package

Getting Started

Install the package and confirm it resolves on your Laravel version before you build anything on top of it:

composer require wpb/string-blade-compiler:^6.0

The 6.0.3 release is a composer.json-only change — no API surface moved, so if you are already on 6.0.x there is nothing to migrate. What it does affect is dependency resolution: re-run composer update wpb/string-blade-compiler and read the released composer.json require block to confirm which Laravel/Illuminate majors the 6.x line actually supports before you assume compatibility.

On Laravel 5.5+ the service provider and StringView facade are auto-discovered. If you are on an older app, or on a version the 6.x constraints no longer cover, register Wpb\StringBladeCompiler\StringBladeCompilerServiceProvider and alias Wpb\StringBladeCompiler\Facades\StringView in config/app.php. Publish the config so you can see where compiled strings land:

php artisan vendor:publish --provider="Wpb\StringBladeCompiler\StringBladeCompilerServiceProvider"
php artisan config:clear

Your first render should be a throwaway unit test — this is the fastest way to prove the compiler instance, cache path, and facade all work in your environment:

use Wpb\StringBladeCompiler\Facades\StringView;

$html = StringView::make('Hello {{ $name }}')
    ->with('name', 'World')
    ->render();

Where to look first:

1. The published config file — note the cache path and any cache toggle. That directory is where compiled PHP for every unique template string is written.
2. vendor/wpb/string-blade-compiler/src/ — read the facade, the custom compiler/engine, and the service provider. You need to know whether it reuses the app's blade.compiler or builds its own; everything in "Gotchas" depends on that answer.
3. composer.json require constraints — the most recent release (6.0.3) was a constraints-only edit, which is a strong hint that Laravel-version support is the actively maintained knob here. Diff the constraint block against your app's laravel/framework version before committing.

First real use case: an admin-editable email or CMS content block stored in the database, rendered with Eloquent models as data. That is the sweet spot — template content is data, not code paths.

Implementation Patterns

Wrap it, don't sprinkle it. Put a single service between your app and the facade so you can swap in Blade::render() later, add logging, and enforce data sanitization:

class TemplateRenderer
{
    public function render(string $template, array $data = []): string
    {
        return StringView::make($template)->with($data)->render();
    }
}

Database / CMS templates. Store the source string, render on demand, and cache the output keyed by template id + a hash of the data. The package caches compiled PHP, not rendered results — you still pay variable interpolation and any model access on every call.

$html = Cache::remember(
    "tpl:{$block->id}:".md5(serialize($data)),
    now()->addMinutes(10),
    fn () => $this->renderer->render($block->body, $data)
);

Compose with normal views. String templates can @include('partials.footer'), @extends('layouts.email'), and call @foreach, @if, @php, and any directives registered on the Blade compiler. Use this to keep layout chrome in real view files and only the editable body in the database.

Mailables and notifications. Render a stored subject/body pair inside a Mailable rather than a full view name:

public function build()
{
    $html = app(TemplateRenderer::class)->render($this->template->body, [
        'user' => $this->user,
        'order' => $this->order,
    ]);

    return $this->subject($this->template->subject)->html($html);
}

Prefer native Blade::render() on Laravel 9+. It does the same job with no dependency: Blade::render($string, $data). The package is still justified on older Laravel versions, or where you want the fluent make()->with()->render() view object and its data accessors. If you're greenfield, take the native path.

Testing. This is excellent for asserting generated snippets: build the template string inline in a unit test, pass fixtures, and assert on the output. No fixtures directory, no view path resolution. Add one integration test that renders a string containing @foreach and @include — it doubles as your upgrade canary on every future release.

Gotchas and Tips

• Treat the template source as code, never as user input. Blade compiles to PHP and the compiled file is included. Passing a string a non-admin typed is remote code execution. Store templates behind admin auth and audit changes.
• Compiled-string cache grows unbounded. Every distinct template string creates a compiled file. High-cardinality templates (e.g. one per user) will bloat storage/framework/views. Run php artisan view:clear on deploy and periodically, and avoid this package for anything user-generated per request.
• Escaping when the string itself comes from Blade. If you're building a template inside a .blade.php file, escape the delimiters (@{{ $name }}) or you'll get double-compilation surprises. If the string is in PHP or the database, use plain {{ }}.
• Custom directives and extensions. Blade::directive(), Blade::if(), and stringable/component registrations attach to the app's blade.compiler. Verify the package uses that same instance — if it constructs its own compiler, your directives silently won't exist inside string templates. Test one custom directive early.
• Stacked sections and @once. @push/@stack/@once write to shared factory state. Rendering several strings in one request (a loop over templates in a mail batch) can leak sections between renders. Keep string templates free of stacks where possible, or flush factory state between renders.
• Errors point at hashed filenames. A parse error in a compiled string reports a path like storage/framework/views/ab12cd...php, not your template. When debugging, log the raw template alongside the rendered output, or dump StringView::make($t)->render() in Tinker with the exact source string.
• Relative includes resolve normally, but component syntax can be brittle. Class-based @component/<x-...> resolution goes through the view finder and is usually fine; anonymous components and slot behavior in a string context deserve a smoke test before you rely on them in production email templates.
• Pin the line and watch the constraint edits. The 6.x line is being maintained, but the most recent patch (6.0.3) touched only composer.json — which means the Laravel/Illuminate version constraints can shift underneath you without any source change. Pin (^6.0 or tighter), lock the version in composer.lock, and let CI catch it: an integration test that renders a string with a @foreach and an @include will fail loudly the day a constraint bump lands on a Laravel major you haven't validated. If a future release does break, migrating to Blade::render() is a handful of lines — the wrapper service makes that a one-file change.
• Config caching. After changing the published config, run php artisan config:clear; the cache path is read at container boot through the service provider. The same applies after any composer.json constraint bump — clear config and views so stale compiled artefacts from a different compiler instance are not reused.