Twig Inspector Bundle Laravel Package

Product Decisions This Supports

• Developer-experience (DX) investment: This is a dev-only tooling package; the decision it informs is whether to spend engineering time on template-debugging ergonomics versus building an internal helper. It directly shortens the loop for "which Twig template/block rendered this DOM node?" — a recurring question in template-heavy Symfony apps.
• Build vs. buy vs. borrow: At MIT license and a single-purpose bundle, the credible option is borrow — install it in the dev environment, pin a version, and fall back to vendoring/forking if maintenance stalls. Building an equivalent overlay from scratch is not worth a sprint.
• Onboarding and handoff cost: Reduces ramp-up time for new engineers and for backend engineers touching frontend templates, and shortens design-system work (locating the template/block behind a rendered component).
• Legacy template sprawl remediation: Informs roadmap decisions around refactoring template inheritance trees — the tool gives visibility into which templates and blocks are actually in use, supporting a "delete dead templates" initiative.
• Not a product-feature decision: This bundle should never appear in a customer-facing roadmap, production dependency list, or architecture diagram. It is a local/dev-only convenience.

When to Consider This Package

Consider it when all of the following hold:

• The stack is Symfony with Twig — note this is a Symfony bundle, not a Laravel/Blade package; the "Laravel/PHP package" framing does not apply here. For Laravel, look at Blade-specific inspector tooling instead.
• Templates are numerous, deeply inherited, or {% embed %}/{% block %}-heavy enough that the standard Symfony Web Profiler Twig panel (which lists rendered templates but does not map them to specific DOM regions) is insufficient for day-to-day debugging.
• You have a staging/dev environment where an in-page inspection overlay is acceptable, and you can gate it behind dev/test config.
• You are willing to pin the version and accept single-maintainer risk (1 star, 0 dependents — essentially unproven in the wild).

Look elsewhere when:

• The stack is Laravel, Blade, or a non-Twig templating engine.
• The team is satisfied with the Symfony debug toolbar + Twig profiler panel; the marginal gain may not justify another dependency.
• You need production-safe instrumentation, an SLA, or vendor support — this is a debugging convenience, not infrastructure.
• Your policy forbids low-adoption/single-maintainer packages even in dev; in that case, fork-and-vendor rather than depend.

How to Pitch It (Stakeholders)

To executives: "A small, free, MIT-licensed developer tool for our Symfony template layer. It's a dev-only install — zero production runtime cost, zero customer-facing risk — and it cuts the time engineers spend hunting for which template produced a chunk of a page. Given near-zero stars and a single maintainer, we treat it as an internal convenience we pin and can replace in a day, not as a strategic dependency."

To engineering leadership: "Cheap DX win for template-heavy codebases: it overlays template/block origin onto rendered HTML in dev. Integration is a composer require plus a dev-only bundle registration; removal is a one-line revert. Trade-off is adoption risk — low stars, no dependents — so we scope it to local/CI-adjacent dev environments and pin the version. Decision to make: adopt as a pinned dev dependency, or skip it if the Twig profiler panel already covers the team's workflow."

To the engineering team: "It answers 'which Twig template and block rendered this element?' without reading the inheritance chain by hand. Try it for one sprint behind a dev-only flag and keep it only if it demonstrably saves debugging time; otherwise remove it. Do not reference it in production configs, tests, or deployment tooling."