Laravel Liquid Laravel Package

Product Decisions This Supports

• Build vs. buy for user-authored templating. This is the decision to not build a template language, sandbox, parser and renderer in-house. Liquid is a well-understood, non-Turing-complete, sandboxed syntax (no arbitrary PHP execution), so it lets non-developers author content without handing them code execution. The auth/guest/env tags being compiled in this release also mean conditional personalization and environment-specific output can be expressed in templates rather than hardcoded per tenant.
• Self-serve customization as a feature. Email/notification templates, invoice and receipt layouts, white-label theming, CMS/marketing pages, and merchant-editable storefront fragments all become customer-editable surfaces rather than engineering tickets. That is a roadmap-level lever: it converts a recurring support/implementation cost into a product capability, and it is often a sales requirement in multi-tenant and agency-facing products.
• Performance/scale roadmap. The headline item here is that Liquid views now compile to PHP artifacts shared between view() and the Liquid facade, with a liquid:cache command wired into php artisan optimize. Previously, per-request parsing was a real ceiling on how aggressively we could put templates on hot paths (checkout emails, high-volume notifications). This changes the answer on "can we use Liquid on the critical path?" from probably not to yes, if we benchmark.
• Streaming/large-output use cases. Liquid::stream() opens up generating large reports, exports and long documents without buffering the whole render in memory — relevant if we want to serve generated PDFs/CSVs/feeds from templates.
• Release/upgrade timing. This is a breaking release with output changes inherited from keepsuit/liquid 0.13. It forces a go/no-go decision with a real migration cost attached (see risks below), and it constrains our Laravel upgrade floor to illuminate/contracts ^11.28, i.e. Laravel 11.28+/12.

When to Consider This Package

Consider adopting when:

• A customer-facing or tenant-facing requirement exists for user-editable templates, and the alternative is either a homegrown templating layer or a much heavier integration.
• The product is on Laravel 11.28+ or 12, or is willing to make that a constraint.
• Liquid/Shopify syntax compatibility is a plus rather than a neutral (e.g. merchants, agencies, or anyone migrating from a Shopify-adjacent stack) — that compatibility is a meaningful onboarding argument.
• Templates are untrusted-ish input from customers, and the sandbox-by-default model is a security win over "let users write Blade/Twig with our app's helpers exposed."
• We can absorb pre-1.0 churn: this is a 0.x package publishing beta releases, so API stability is not contractual.

Look elsewhere when:

• The need is internal-only templating for our own developers. Blade already does this, it is first-party, and adding a second template language to the codebase is a tax with no user-facing payoff.
• The team is pinned below Laravel 11.28 — this release hard-drops that path.
• Full Twig/Jinja expressiveness or a mature plugin/extension ecosystem is required; Liquid is deliberately limited, and that limitation will surface as feature requests.
• The roadmap requires guaranteed output stability for persisted, user-authored templates and there is no appetite for a validation/migration harness. The 0.13 output changes (integral floats rendering 3.0, decimal arithmetic in math filters, parse-time SyntaxException on incomplete conditions, empty tags, duplicate for/else sections, missing filter args) will change or break stored templates.
• We need production support/SLAs and a stable release channel — this is beta, and should be treated as such (see pitch below).

How to Pitch It (Stakeholders)

To executives: This upgrade turns our templating layer from a per-request cost into a compiled, cacheable asset, and it does so on a dependency line that is already the safe choice for letting customers edit their own content. The one-line version: customer-editable templates without letting customers run code. The concrete asks are modest — pin to an exact version, gate rollout behind a flag, and budget a short migration pass on existing stored templates.

To engineering: v0.7.0-beta.1 is a breaking release, but it buys real capability: Liquid views compile to PHP artifacts shared between view() and the Liquid facade, liquid:cache is now part of php artisan optimize, Liquid::stream() exists for large renders, and auth/guest/env tags compile instead of being interpreted. The cost is an upgrade floor (keepsuit/liquid ^0.13, illuminate/contracts ^11.28, support for 0.7–0.12 dropped) plus inherited output changes: integral floats now render 3.0, math filters use decimal arithmetic, and malformed templates that previously rendered garbage now throw SyntaxException at parse time.

Recommended posture — adopt, but as a controlled migration:

1. Pin exactly to the beta while it is beta; do not float the constraint. Treat 0.x minor bumps as breaking by default.
2. Add a pre-flight template lint job that parses every stored template and fails the deploy on SyntaxException. The new parse-time strictness is the good kind of breaking change — but only if we surface it before customers do.
3. Snapshot-test rendered output for float-heavy templates, since 3 → 3.0 is the change most likely to be noticed by a merchant and least likely to be caught by our own tests.
4. Benchmark before claiming the win. Compilation is a genuine improvement only if our cache invalidation story is correct; confirm php artisan optimize populates the cache in the deploy pipeline and that template edits invalidate cleanly.
5. Ship behind a flag, and keep the previous pinned version as the documented rollback.