Twig Lambda Laravel Package

Product Decisions This Supports

• Feature scoping for view-layer data shaping. This package lets templates declare inline lambda/arrow functions and pass them to collection filters (map, filter, reduce, sorting). That directly informs whether a feature like "customizable dashboards," "user-defined report filters," or "conditional content blocks" can be delivered in the templating layer versus requiring new controller endpoints or service classes.
• Build vs. buy for presentation logic. If the roadmap includes configurable UI behavior (theme authors, content editors, or low-code admin users writing transform rules), this is a candidate to buy/borrow rather than build. It replaces bespoke "helper filter" work in the view layer with a general, composable primitive.
• Architecture decision: where transformation lives. Adopting it signals a deliberate choice to keep lightweight collection transforms in views instead of pushing every variation into view models or presenters. That tradeoff should be made once, as policy, not per-ticket.
• CMS/extension roadmap. If the product ships a Twig-based surface (Craft CMS, Drupal, Symfony/TwigBridge on Laravel), this expands what customers can express without code changes — relevant to platform/extensibility roadmaps.
• De-risking template complexity. Existing templates that nest loops and conditionals to fake filters can be simplified, which reduces bug surface in view code and shortens review cycles for template-touching tickets.
• Not a strategic dependency. At 45 stars, a single-maintainer profile, and a last release in June 2018, this should be evaluated as an optional, isolated capability — not something the roadmap is allowed to depend on for a launch-critical path.

When to Consider This Package

Consider it when:

• You are on a Twig version without native arrow functions (broadly pre-Twig 2.10 / 2.x era) and cannot upgrade on the roadmap's timeline. This is the single strongest reason to adopt.
• Your team owns a Twig-based surface — Symfony, Craft CMS, Drupal, or Laravel via TwigBridge — not a Blade-only Laravel app.
• You have repeated, concrete template patterns (filtering a collection by a field, mapping to a display value, reducing to a total) appearing across many templates, currently duplicated as one-off filters or nested loops.
• You want the capability behind a feature flag or a contained set of templates, so removal is a one-line config change if the package stalls.
• You can accept maintainer and compatibility risk and have someone who can vendor or fork a ~small extension if needed.

Look elsewhere when:

• You are on Twig 2.10+ or 3.x, where arrow functions and the core map/filter/reduce/sort filters largely cover this. Upgrading Twig is a better investment than adding a dependency.
• You are Blade-first on Laravel — Illuminate\Support\Collection already provides map/filter/reduce; pushing lambdas into Blade is a step away from the framework's grain.
• The real need is business logic, not presentation: pricing rules, permissions, eligibility. Those belong in services or view models, and template lambdas would hide testability and auditability problems.
• You run Twig sandbox / untrusted template authors. Inline executable expressions widen the attack and review surface; treat that as a security review gate, not a footnote.
• You need vendor-supported SLAs, PHP 8.x guarantees, or a maintained release cadence. Last release 2018 makes those unavailable.

Gate before adoption: verify the version constraint against your PHP runtime and Twig version, run it under your template linting and sandbox policy, and confirm a rollback path. Absent that, the honest answer is "upgrade Twig instead."

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Twig extension that makes templates more expressive — authors can filter, map, and total collections directly instead of requesting new endpoints. It is cheap to try and cheap to remove. The caveat is maturity: 45 stars, one maintainer, last release in 2018, so it should be treated as an optional convenience rather than a platform dependency. Recommended posture: evaluate as a scoped experiment, not a standards decision.

To engineering: It buys us arrow functions and lambda-driven filters on Twig versions that lack them natively. If we're on Twig 3.x, the value proposition mostly evaporates and the correct move is upgrading Twig. If we're pinned to an older Twig and have recurring collection-transform templates, this removes duplication and nested-loop workarounds. We should isolate it behind a Twig extension registration and a config flag, keep it out of any launch-critical path, and be prepared to vendor or fork given the release history.

To design/content stakeholders: It expands what's expressible in templates — useful if we want theme or template authors to build richer list and summary views without engineering tickets. It does not change the authoring UI, and it will not make complex business rules safe to express in templates; those still route through engineering.

Recommendation: Adopt only as a contained, reversible capability gated on a Twig-version check; otherwise prioritize a Twig upgrade, which delivers the same outcome with a maintained dependency.