Sensio Buzz Profiler Bundle Laravel Package

Product Decisions This Supports

First, correct the framing: this is not a Laravel package. It is a Symfony 2-era bundle that wires sensio/buzz-bundle into juliendidier/buzz-profiler-bundle so the default Buzz client shows up in the Symfony web profiler. Laravel does not load Symfony bundles; the only shared DNA is Symfony components. Any roadmap item that treats this as a Laravel dependency is mis-scoped before it starts.

Decisions it can legitimately inform:

• Legacy Symfony 2.x maintenance vs. freeze. If a product line still runs Symfony 2.x with sensio/buzz-bundle, this package is the cheapest way to get outbound HTTP calls visible in the dev toolbar during incident triage. That is a maintenance-budget input, not a feature input.
• Buy vs. build for observability. The entire capability is a small compiler-pass/service-decoration shim. If profiling outbound HTTP is a requirement, the build decision should be "use the platform's built-in collector," not "adopt an unmaintained glue bundle."
• Roadmap: modernization sequencing. The existence of this package in a composer.json is a reliable archaeological marker: the app is on Buzz (abandoned in favor of PSR-18/PSR-7 clients), Symfony 2, and a PHP version well below 8. That single signal can justify prioritizing a client migration (Buzz → Symfony HttpClient or Guzzle with history middleware) ahead of feature work.
• Due-diligence / acquisition review. Useful as a checklist item when assessing inherited codebases: presence implies dev-only tooling on a dead HTTP stack, which implies broader dependency debt.
• Explicit non-decision: do not feature-flag or vendor this. With 1 star and 0 dependents there is no upstream to lean on, no security response path, and no compatibility work for modern PHP.

The 4.16 "opportunity" score should be read as a supply vacuum, not demand: nobody maintains this because the underlying Buzz stack is EOL, not because the market is underserved.

When to Consider This Package

Adopt only when all of the following hold:

• The application is Symfony 2.x, running PHP 5.5–7.2, and already depends on sensio/buzz-bundle.
• juliendidier/buzz-profiler-bundle is already installed and working.
• You specifically need the default configured Buzz client instrumented (rather than a hand-registered one), and a one-line service decoration is genuinely cheaper than duplicating the collector wiring.
• It stays in require-dev, in dev/test environments only, behind a pinned composer.lock.
• There is no near-term PHP or Symfony upgrade on the roadmap — because the moment there is, this package is dead weight.

Look elsewhere when:

• The stack is Laravel. Use Laravel's HTTP client with Telescope/Http::withOptions or a Guzzle history middleware. There is nothing here to port.
• You are on Symfony 4+ / PHP 8. Use Symfony HttpClient's built-in profiler panel and TraceableHttpClient; the profiler integration is first-party and maintained.
• You need any PSR-18/PSR-7 client. Buzz is not that ecosystem; instrument Guzzle, Symfony HttpClient, or an HTTPlug adapter instead.
• You require security advisories, CI against modern PHP, or an SLA. This package offers none, and its transitive dependencies won't either.
• You're evaluating it for new development. Don't. A one-star, zero-dependent glue bundle is a symptom to be scheduled away, not a component to standardize on.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated olegstepura/sensio-buzz-profiler-bundle and recommend not adopting it. It is a tiny, unmaintained Symfony 2-era integration that adds outbound-HTTP visibility to the dev profiler in legacy applications. It is not a Laravel package, it has one star and zero dependents, and it targets an HTTP client and framework version that are both end-of-life. There is no cost to leaving it out and no material capability lost — the same profiling is available first-party in modern Symfony and Laravel. Where we find it in our own or acquired code, treat it as a modernization signal, not a dependency to support.

To engineering: Functionally it is a compiler pass / service decoration that attaches the profiler's middleware to the client defined under sensio_buzz. That is roughly a day of work to reproduce and no reason to inherit the maintenance risk. Recommended path: (1) inventory where sensio/buzz-bundle appears; (2) replace Buzz with Symfony HttpClient (or Guzzle + history middleware) and use the platform's native profiler collector; (3) delete this bundle along with the rest of the Buzz dependency chain; (4) re-verify outbound-call tracing in staging before closing the migration. Until step 3 lands, keep it require-dev-only and behind a pinned lock file — never in production autoload.

Risk statement: dev-only tooling, so production blast radius is low; the real risk is the adjacent signal — an EOL HTTP client and framework that do run in production.