String Blade Compiler Laravel Package

Product Decisions This Supports

Build vs. buy on template rendering. This package answers a narrow question — "can we render a Blade template that lives in a database column instead of a .blade.php file?" — with a ~1-class wrapper instead of a custom compiler harness. That is a decision worth a 1–2 day spike, not a multi-sprint build.

Feature: user-editable / admin-editable content surfaces. It unlocks a roadmap item that otherwise stalls: letting non-engineers change templates without a deploy. Concretely:

• Transactional email and notification templates customizable per tenant/plan/brand (the highest-value use case by far).
• Invoice, receipt, and PDF body templates stored with the billing configuration rather than the code.
• White-label / multi-tenant overrides: same template key, different string per tenant, resolved at runtime.
• CMS-style content blocks, help-center snippets, and landing-page fragments rendered server-side.
• Webhook/export payload mapping and placeholder substitution ("Hello {{ $customer->name }}") where a full view file per integration would be absurd.
• Template preview and "render as this user" tooling in admin, plus golden-file tests over template strings.

Roadmap sequencing signal. The "self-serve template editor" epic is only cheap if string rendering is a solved primitive. If we adopt this, that epic becomes UI + validation + versioning work. If we don't, the epic carries a hidden platform task, and it should be re-scoped or deferred.

Risk decision: who is allowed to author templates. This package executes Blade, and Blade can execute PHP. The real product decision it forces is whether templates are authored by trusted internal staff (low risk, ship it) or customers (needs a sandbox, and Blade is the wrong engine for that). Deciding this early prevents an "admin template editor" from quietly becoming an RCE surface.

Strategic weighting: tactical, not foundational. Still ~172 stars, zero dependents, one maintainer. The only release activity since December 2020 is a composer.json-only patch (6.0.3) — that is a metadata/constraint edit, not renewed maintenance. Treat it as a small utility we can vendor or fork, not a platform bet. Opportunity score of ~21 confirms it: real but niche, so don't let it drive architecture.

When to Consider This Package

Adopt when all of these hold:

• You are on an older Laravel line (roughly 5.5–8.x) where the framework has no first-class string rendering, or you're pinned there for other reasons.
• Templates are authored by trusted internal users or seeded from version-controlled fixtures — not typed in by customers.
• You need exactly one thing: render(string, data). No custom directives, no per-tenant include resolution, no sandboxing.
• The integration is a few call sites (emails, notifications, a PDF builder), not a general-purpose templating layer.
• You're willing to vendor the source into app/ or a private fork on day one, with a smoke test that pins the behavior you rely on.

Look elsewhere when any of these hold:

• You're on Laravel 9+. The framework now ships Blade::render() (plus component and slot support). That is a supported, upgraded-with-the-framework path to the same outcome, and it makes this package redundant. Check your Laravel version before anything else — this is the single biggest disqualifier.
• Untrusted authors. If customers write the templates, Blade is the wrong tool regardless of package. Use Twig with its sandbox extension, Liquid, or a purpose-built allowlist renderer. Retrofitting a sandbox onto Blade is the expensive path.
• You need maintained compatibility. 6.0.3 changed composer.json and nothing else — no changelog entry, no source change, no test evidence. Do not read it as "Laravel 9/10/11 and PHP 8.2+ are supported"; read the constraints yourself before trusting them. If your upgrade cadence is annual, plan on maintaining this yourself within a year.
• You need real template lifecycle features — versioning, diffing, per-tenant include resolution, compile caching at scale, invalidation on edit. This package gives you the render primitive and nothing else; budget the surrounding system separately.
• Zero-dependents matters to your security review. There is no crowd-sourced validation of edge cases here. Expect to read the source (it's small — that's the upside) rather than rely on ecosystem pressure-testing.

Decision shortcut: run a half-day spike. Does Blade::render() in our current Laravel version cover the requirement? If yes, close the ticket. If no because we're on Laravel 8, this package is a reasonable stopgap — vendor it and put a removal ticket against the framework upgrade. If the 6.0.3 constraint bump is what makes it installable at all, capture that pin explicitly in the spike notes so a future composer update doesn't silently move us.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT), single-purpose utility that unblocks self-serve template customization — letting customers and support staff change email, invoice, and notification wording without engineering involvement or a release. Cost is hours of engineering, not weeks. The honest caveat is maintenance: the library's last substantive release was December 2020, and its only recent activity is a packaging-only patch, so we'd take a copy in-house rather than depend on the author. We should approve it as a tactical enabler with a known expiry date, not as a platform commitment. The one thing to decide now is scope: if templates are ever customer-authored, the security work changes the estimate by an order of magnitude.

To engineering: It's a thin wrapper that compiles a Blade string through Laravel's own compiler and renders it with a data array — no new template language, no new caching model, your existing Blade knowledge applies. Three things to verify before we commit: (1) whether Blade::render() in our Laravel version already does this, which would make the dependency unnecessary; (2) framework and PHP version constraints against our matrix — 6.0.3 touched only composer.json, so diff the constraints against 6.0.2 rather than assuming support was added; (3) that compiled-string caching and view:cache behave sanely in our deploy. If any of those are shaky, we vendor the source — it's small enough to own — and keep the public call sites behind our own interface so swapping engines later is a one-file change.