Templating Extra Bundle Laravel Package

Product Decisions This Supports

• Observability / performance roadmap: Informs whether template-render profiling belongs in our standard local/staging tooling. Template rendering is a recurring source of "mystery latency" in server-rendered apps, so this sits in the same decision space as APM, query logging, and cache-hit-rate monitoring.
• Build vs. buy (vs. already-have): The core decision this package actually forces is "do we need this at all?" Modern Symfony's WebProfiler + Twig data collector already surface rendered templates and per-template timings in the profiler panel. That makes the real decision "use native tooling" rather than "buy this."
• Framework fit: This is a Symfony bundle, not a Laravel package. It is not installable or useful in a Laravel/Blade codebase. If our stack is Laravel-first, the decision is a fast "out of scope" — it only enters the picture for any Symfony services in the portfolio.
• Use cases it would support (if adopted): identifying over-rendered partials/includes, spotting N+1-style template-include explosions, finding slow or frequently-rendered Twig fragments, and building a template inventory for refactor planning (e.g., consolidating duplicated partials).
• Dependency-risk policy: 6 stars, 0 dependents, single-maintainer — this is a data point for our "third-party dependency vetting" standard, not a feature decision. Good candidate for reading the source and reimplementing rather than depending on it.
• Not supported: production runtime profiling, user-facing features, or anything requiring ongoing maintenance guarantees.

When to Consider This Package

Consider (cautiously) only if all of the following hold:

• The service in question is Symfony, on a version this bundle actually supports — verify composer.json constraints against our PHP/Symfony versions before anything else. Low-star bundles from the Symfony 2/3 era frequently fail on modern Symfony (5/6/7) due to removed APIs.
• We have a specific, reproducible template-render performance problem and native profiler output is insufficient (e.g., we need aggregated/flattened template metrics across a request in a form we can export or diff).
• We need the data outside the interactive profiler — CI perf budgets, before/after refactor comparisons, or staging-only sampling.

Look elsewhere (or do nothing) when:

• Native Symfony profiler/Twig data collector already answers the question — the default answer for most teams.
• The stack is Laravel/Blade — irrelevant; Laravel's Telescope/Debugbar cover adjacent ground.
• Maintenance risk is unacceptable: 0 dependents and a single maintainer mean no community backstop for security or compatibility fixes. Treat as unmaintained until proven otherwise.
• You need production-safe, low-overhead profiling — dev-tool bundles typically assume the debug/profiler stack is enabled and are not designed for always-on production use.
• A general APM (Blackfire, Tideways, OpenTelemetry) already gives template-level spans — that's the more durable investment.

Recommendation: do not add as a runtime dependency. Time-box a spike to read the source (it is small) and confirm native profiler parity; if a gap exists, implement the collector in-house under our own maintenance.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated mremi/templating-extra-bundle, a small Symfony utility that reports which templates get rendered during a page request and how long each takes. Our recommendation is not to adopt it. It is a Symfony-only tool with negligible adoption (6 stars, zero dependent projects, one maintainer) and overlaps with profiling capability we already get for free from Symfony's built-in web profiler. It also provides no value on our Laravel services. Adopting it would add a maintenance liability without adding a capability.

For engineering leadership: The problem space is real — template rendering is a legitimate blind spot in server-rendered performance work, and per-template timing is genuinely useful for finding over-rendered partials and slow fragments. But the tooling gap has largely closed: Symfony's Twig data collector covers the common case inside the profiler. If we hit a case it does not cover (aggregated metrics across requests, CI perf gates, refactor diffing), the right move is a small in-house data collector we own — roughly a day of work — rather than a single-maintainer dependency with no downstream users.

For the engineering team (practical guidance):

• First, confirm framework fit: this is a Symfony bundle, not Laravel. Laravel services are out of scope.
• Before writing any code, reproduce the suspected template slowness and check the Twig panel in the Symfony profiler. Most "we need a template profiler" tickets close here.
• If a gap remains, prefer Blackfire/Tideways/OpenTelemetry spans for anything that must run in staging or production; dev-only bundles are the wrong vehicle for continuous measurement.
• If we do build in-house, keep it behind the debug flag (kernel.debug) or a feature toggle so it can never affect production request cost.
• Record the outcome in our dependency-vetting log either way — a documented "no" with the reason (native parity, maintenance risk) is a reusable decision, and this pattern will recur with other single-maintainer Symfony bundles.