Twig Bundle Laravel Package

Product Decisions This Supports

• Templating strategy: Twig vs. Blade. This package is a forcing function for the question "do we want first-class template helpers (asset tags, image markup, form rendering, session access, number formatting) without hand-rolling them?" It informs whether Twig is a viable second view layer alongside Blade for server-rendered or hybrid surfaces.
• Build vs. buy for view-layer utilities. A PM scoping a sprint of custom Twig extensions (image, tag, css/js, unset, number, session) can use this as a ready-made "borrow" baseline — it plausibly short-circuits a sprint of utility work, at the cost of an unmaintained dependency.
• Framework alignment for a Laravel shop. Critical caveat: despite the Laravel/PHP framing, this is a Symfony bundle (LidaaTwigBundle), wired through a Symfony kernel, DI compiler tags, and twig.extension services. It does not install into Laravel's container. The real product decision is Symfony vs. the Laravel community twigbridge — which changes cost/benefit materially.
• Feature-parity checklist for a migration. If the team is porting Jinja/Twig-style templates, this bundle is a reference for which extensions the product actually needs before committing to an in-house extension library.
• Roadmap risk triage. 24 stars, 0 dependents, low score: not a candidate for a customer-facing critical path; appropriate for spikes, internal tooling, or vendored code.

When to Consider This Package

Consider it when:

• You are on Symfony (not Laravel) with Twig and want convenience extensions (url, image, css, js, tag, session, number, form, html, unset) without writing them yourself.
• You are running a time-boxed spike or prototype where the fastest path to a working template layer beats long-term maintenance.
• The surface area is small — internal admin tooling, one-off marketing pages, a throwaway MVP — so the blast radius of an unmaintained dependency is limited.
• You are willing to pin, vendor, or fork the extension classes into your repo, treating the package as a starting template rather than a live dependency.

Look elsewhere when:

• You are on Laravel — wrong framework abstraction. Use rcrowe/twigbridge, or stay on Blade with equivalent helpers.
• The feature is customer-facing or on a critical path. Zero dependents and 24 stars is a strong bus-factor signal; there is no upstream maintainer commitment to rely on.
• You need security-sensitive helpers (php execution, session access) with audited maintenance. Symfony's first-party twig-bridge already covers the safe equivalents (asset, form, html, session, trans).
• Your org gates third-party code via supply-chain or license review; an unmaintained bundle will not clear it.
• You want long-term support — prefer first-party twig-bridge or a small in-house extension set you own.

How to Pitch It (Stakeholders)

To executives (one paragraph):

This is a small community Twig extension bundle that would save us from building common template helpers (image markup, CSS/JS tags, form rendering, number formatting) from scratch. It is low-cost to trial but a narrow, low-adoption dependency — 24 stars, zero downstream dependents, no visible maintenance. Recommendation: allow it in an isolated spike to validate the template approach; do not place it on a customer-facing critical path without a fork-and-own plan. Budget the "buy" as a reference implementation, not a platform commitment.

To engineering leads:

It's a Symfony bundle, not a Laravel package — confirm framework fit first. On Symfony/Twig it overlaps heavily with official twig-bridge; the delta is convenience extensions (image, tag, css, js, unset, number). Two hard risks: (1) the php extension turns every template into an arbitrary-code-execution surface, so it must be disabled or allowlisted before any use, and (2) the package is effectively unmaintained, with Twig 1.x-era APIs that need mechanical rewrites for Twig 3. Plan to vendor or fork the extension classes into our codebase and own them. Treat it as a reference implementation for our own extension library, not a live dependency.