Laravel Latte Laravel Package

Product Decisions This Supports

• View-layer standardization. Decides whether Blade remains the single templating contract across the product or whether Latte becomes a sanctioned second engine. This package is the concrete artifact for that "two engines vs. one" call — it lets you scope the integration cost before committing.
• Migration and tech-debt sequencing. If you are porting a Nette/Latte codebase, a Latte-experienced team, or an acquired product onto Laravel, this package determines whether you migrate templates or engines. That directly changes the size, risk, and timeline of a migration epic.
• Security posture for user-authored templates. Latte's sandbox and context-aware auto-escaping are the reason to look here. If a roadmap item involves letting customers, partners, or internal non-engineers author templates (notifications, documents, white-label storefronts), this is a genuine architecture decision — and an integration like this is how you'd evaluate it cheaply.
• Build vs. buy vs. wire-up. The alternative to adopting this package is writing and owning the bridge yourself. At a few hundred lines of service-provider glue, "adopt, vendor, or fork" is a real PM tradeoff between upfront cost and long-term maintenance ownership.
• Dependency risk register. 4 stars, 0 dependents, and a single maintainer make this a named item in your third-party risk inventory, not a silent transitive dependency. That framing shapes whether it's approved for internal tools versus customer-facing surfaces.
• Experimentation budget allocation. A low-cost spike (one squad, one internal surface, a short timebox) can answer "does Latte's ergonomics actually help us?" far cheaper than an architecture debate.

When to Consider This Package

Consider it when:

• Your team already knows Latte and the productivity delta justifies a non-standard view layer.
• You have a body of existing .latte templates you want to reuse rather than rewrite into Blade.
• A product requirement needs template sandboxing or stricter escaping guarantees than Blade gives you by default, and Latte is your candidate.
• The integration is scoped to internal tools, admin surfaces, or a bounded service where blast radius from abandonment is small.
• You are willing to vendor or fork the package and own the integration — i.e., you have PHP depth on the team and treat this as "we are adopting Latte," not "we are depending on a library."

Look elsewhere when:

• Blade already covers the need. Most Laravel products should stop here; a second engine is a permanent tax on onboarding, code review, and tooling.
• You rely heavily on Livewire, Inertia, or a Blade-component design system — dual-engine setups fragment that ecosystem and rarely pay off.
• You need a supported dependency with a maintenance commitment, LTS posture, or an SLA. Zero dependents and a single maintainer is a bus-factor of one.
• No one on the team has Latte experience. The learning curve plus the integration cost is not offset by anything this package uniquely provides.
• The surface is revenue-critical and long-lived. Here you want the ecosystem default unless you have a compelling, documented reason otherwise.

How to Pitch It (Stakeholders)

For executives: This is a small, reversible bet — not a platform change. It lets us test whether Latte's templating (mainly its security sandbox and escaping model) unlocks a capability we'd otherwise build ourselves, at the cost of one engineer for a timeboxed spike. The risk profile is explicit and contained: MIT-licensed, tiny dependency, no downstream users, single maintainer — so we would only use it behind a bounded surface, with a documented exit path back to Blade. Recommendation is a spike, not an adoption.

For engineering: This is a thin Laravel service-provider bridge to Latte, not a framework. It gives us Latte's compilation, caching, strict auto-escaping, and sandbox in a Laravel app, alongside — not instead of — Blade. The honest caveats: near-zero adoption, no dependents, one maintainer, and no release cadence guarantees. So the ask is to evaluate it as a starting point we may vendor or fork, wire it into a single non-critical surface, and measure whether the template ergonomics and security model earn the second-engine cost. If the spike says no, we've spent a week and learned something. If it says yes, we take on ownership deliberately rather than accidentally.