Twig Service Bundle Laravel Package

Product Decisions This Supports

• Framework-fit decision (make this first). This is a Symfony bundle, not a Laravel package. Its value proposition only exists where Twig is the template engine. In Laravel that means adding twig/twig plus a Twig-for-Laravel bridge — an extra moving part and a second templating dialect alongside Blade. For a Laravel shop, this is a "no" on fit before any feature merits are discussed; for a Symfony shop, it's a genuine "maybe."
• Build vs. buy on template plumbing. Every small helper — a price formatter, a feature-flag check, a nav/menu builder, a config read — normally costs a Twig extension class plus tests. This package collapses that into configuration. The buy-side cost is one MIT dependency; the build-side cost is roughly half a day per helper, recurring.
• Roadmap unblocking. Lets content/marketing-driven pages (CMS blocks, landing pages, admin dashboards, multi-tenant theming) pull from existing read-only services without an engineering ticket per variation. Good fit for "we need this page to show X" requests that currently queue behind platform work.
• Architecture guardrail decision. Adopting it is implicitly a decision that templates may call services directly. That widens the surface where business logic can leak into views. The package forces you to decide, explicitly, which services are template-safe (read-only) and which are not — a useful forcing function, but a decision you must own rather than default into.
• Prototyping and internal-tool bets. Strong fit for spikes, back-office tools, and low-blast-radius internal pages where the cost of a "proper" extension layer isn't justified.

When to Consider This Package

Adopt when:

• You are on Symfony with Twig already in place (this is the gating criterion).
• You have a small, bounded set of simple, read-only helpers and don't want a class per helper.
• Your team accepts convention-based access and will document which services are exposed.
• You treat it as an ordinary dev dependency you can pin and drop, not as infrastructure.

Look elsewhere when:

• You are on Laravel. Blade's @inject, view composers, and custom directives already solve most of this natively; introducing Twig to get this package is a poor trade.
• Helpers are numerous, stateful, or business-critical — write explicit Twig extensions or view models instead; you want names, types, and tests at the boundary.
• You need template sandboxing or a strict no-logic-in-views policy — direct service access works against that.
• You require vendor-backed support or a large community. Signals here are thin: ~13 stars, zero dependents, low overall score. The December 2025 release is a positive maintenance signal, but adoption risk is real and should be priced in.
• You cannot absorb the cost of removing it later — mitigate by confining usage to a handful of templates so a revert is a day, not a quarter.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed utility that removes a recurring bottleneck — the "we just need one value on one page" request that currently consumes an engineering cycle. It is cheap to trial and cheap to abandon. The honest caveat: it is a niche, low-adoption package (double-digit stars, no downstream dependents), so recommend it as an optional developer tool with a bounded pilot, not as core platform infrastructure. Success looks like fewer template-helper tickets and no increase in template-related defects.

To engineering: One Composer dependency that exposes functions, static methods, and Symfony service methods to Twig, replacing a class-per-helper pattern. It's maintained (recent release) and permissively licensed. Two conditions for approval: (1) confirm we're standardized on Twig — if the ask is really about Laravel, this is the wrong tool and we should use Blade primitives; (2) we publish an allow-list of read-only services and keep mutating services out of templates. If either condition fails, we build the thin extension layer instead.