Blade Laravel Package

Product Decisions This Supports

• Template-engine standardization across a mixed estate. If your organization runs Laravel for core products but Leaf/PHP-microservice code for satellite services (admin panels, internal tools, marketing microsites), this package lets you keep one templating mental model — Blade — instead of maintaining Leaf's native templating dialect in parallel. That is a real onboarding and documentation cost saver.
• Build vs. buy on glue code. The only alternatives are (a) writing your own Blade↔Leaf service-provider shim, or (b) refactoring off Leaf. Both are more expensive than adopting a small adapter. This package is a "buy" only in the sense of don't write it yourself — it is roughly a service-provider wrapper around jenssegers/blade, not a platform. v5.0 does not change that calculus, but it does enlarge the surface you would inherit if you fork (see the Lingo note below).
• Design-system reuse. If your component library, partials, and layout conventions already exist as Blade components, this is the cheapest path to reusing them in a Leaf service rather than re-implementing them. That is a product-facing decision (consistent UI, faster feature delivery), not just an engineering one.
• Localization strategy (new in v5.0). The new @lingo and @tl directives mean translation calls can live inside the templates rather than being pre-resolved in controllers. If you already use Leaf Lingo for i18n, this is a genuine consolidation — one place for copy, one workflow for translators. If you use Laravel's __()/@lang or a third-party translation service, this adds a Leaf-specific dialect your Blade templates will not carry back to Laravel.
• Error triage and on-call load (new in v5.0). Blade renders now leave breadcrumbs in Leaf Crash, showing which views rendered before a crash and how long each took. For a PM this is a small but real operational win: faster root-cause on template-related incidents, less time spent reconstructing "which page actually blew up." Worth weighing if your services are thin-staffed on support.
• Exit-strategy and lock-in planning. Templating is a shallow, well-bounded seam, so adopting Blade over Leaf's native engine still reduces framework lock-in overall — templates remain portable to Laravel, Lumen, or standalone jenssegers/blade. Caveat added in v5.0: any template using @lingo/@tl is no longer portable without a shim. Decide whether those directives are permitted in shared components; if portability is the reason you are adopting, ban them outside Leaf-only views.
• Roadmap risk line item. With ~4 stars, 0 dependents, and a low composite score (16.4), this must be logged as a single-maintainer dependency in your technical-debt register, with an explicit fork-and-own contingency. A PM should decide up front whether the team is willing to own the fork — because statistically, they will have to. v5.0 shipping is mildly reassuring (the maintainer is active) but does not change the structural risk.
• Platform-currency planning. v5.0 requires PHP 8.2+ and Illuminate ^11 | ^12 | ^13. That is a forcing function: it locks the package to your Laravel component upgrade cadence. Good for security posture, bad if your Leaf services deliberately run older runtimes — the template layer would then dictate your PHP floor.

When to Consider This Package

Adopt (narrowly) when:

• You are already committed to Leaf PHP and are not evaluating a framework change.
• Your runtime is PHP 8.2+ and your Laravel side is on Illuminate 11, 12, or 13 — v5.0 will not install otherwise. Confirm this before the spike, not during it.
• A concrete, existing Blade asset exists — a component library, a design system, or a team fluent in Blade — that you want to reuse verbatim.
• You use Leaf Lingo for translations and want copy authored in templates via @lingo/@tl.
• You want better incident forensics and are willing to wire Leaf Crash breadcrumbs into your error reporting.
• The scope is small and bounded: marketing pages, admin CRUD screens, internal dashboards. Templating is a shallow dependency and is cheap to reverse.
• You can pin a version, vendor the source, and assign a named owner for the fork. Treat it as internal code from day one.

Look elsewhere when:

• Leaf's native templating is sufficient. Leaf ships its own Blade-inspired engine; adding this package may be pure redundancy. Confirm the gap before adopting — a PM should demand a one-page justification of what Blade gives you that Leaf's engine does not. v5.0 does not settle this argument; the Lingo directives are the strongest new answer, and only if you actually use Lingo.
• You are on PHP 8.1 or Illuminate 10 or earlier. v5.0 is a hard break. Either stay on v4 and own that branch, or upgrade — cost that into the decision.
• You need active maintenance, CVE response, or vendor support. 4 stars and 0 dependents is not a community; it is one person's repository. The v5.0 release shows activity but not a support contract. For anything customer-facing or regulated, that is disqualifying without a fork plan.
• You are already on Laravel. Use laravel/framework or jenssegers/blade directly; this package adds a Leaf-specific layer for no benefit.
• You expect deep ecosystem integration. Do not assume Livewire, Blade UI kits, or Laravel-specific directives behave identically through this adapter. v5.0 narrows the version gap to Laravel but does not certify feature parity — validate each directive and integration you depend on, including the new Lingo ones.
• Performance is the binding constraint. Blade compiles to plain PHP and is fast, but the extra indirection, cache-path configuration, and now the Leaf Crash breadcrumb instrumentation on a non-Laravel host deserve a benchmark before you standardize.
• Your test strategy assumes portability. The suite now runs through Alchemy (Leaf's testing stack). Tests written against this adapter will be Leaf-flavored; budget for that if a future migration is on the table.

How to Pitch It (Stakeholders)

To executives: This is a small, free adapter that lets our Leaf-based services use the same page-templating technology as our Laravel products. The upside is one skill set, one component library, and faster delivery on smaller services. Version 5.0 just shipped with two useful additions — better crash diagnostics (you can see which page rendered before a failure) and in-template localization support — plus a requirement bump to PHP 8.2+ and current Laravel component versions. The cost is near zero to try. The risk is unchanged and structural: the project has effectively no community and a single maintainer, so if we adopt it we should budget a few engineering days to take ownership of a private copy. Recommendation: approve a two-week, time-boxed spike on one low-stakes service — not a company-wide standard — and confirm our PHP baseline first, since 5.0 drops older runtimes.

To engineering: Treat this as glue, not a framework. It is a Leaf service provider wrapping jenssegers/blade; the surface area is small enough to audit in an afternoon. v5.0 requires PHP 8.2+ and Illuminate ^11 | ^12 | ^13 — verify both before promising a date, and decide deliberately whether @lingo/@tl are allowed in shared components, since they break template portability. Note the test suite now runs through Alchemy, so our tests will inherit Leaf conventions. If the spike succeeds, vendor the source into our mono-repo, pin it, and own it — do not depend on upstream releases. Please also confirm what Leaf's built-in engine already gives us, so we adopt this for a stated reason rather than familiarity.

Framing to avoid: Do not position this as a strategic platform decision or a step toward Blade everywhere. It is a tactical convenience with a known maintenance tail, and it should be scoped, reversible, and owned. The v5.0 feature set is welcome, but it is not evidence that the dependency risk has changed.