- Is iluckhack/xhprof-buggregator-bundle a Laravel package?
- No. It is a Symfony bundle built on FrameworkBundle's bundle registry, a DependencyInjection extension, a Configuration tree, and config/packages YAML, none of which Laravel implements. Laravel's use of Symfony components such as HttpFoundation, Console, and Process does not extend to the bundle system, so nothing auto-wires in a Laravel application.
- Can I install this package in a Laravel app with Composer?
- Composer will install it, but the package is inert in Laravel: there is no service provider, no publishable config file, and no middleware. Reuse means copying the small profiler and payload classes and adapting them yourself, not calling the bundle. Treat it as a reference implementation rather than a dependency.
- How do I install and configure the bundle in Symfony?
- Require it with Composer, register the bundle in config/bundles.php, then set the Buggregator host and port in config/packages. It expects the XHProf PHP extension to be loaded and a running Buggregator server to receive the profiles. Symfony's bundle mechanism handles all the wiring.
- What PHP and XHProf extension requirements does this package have?
- The XHProf extension must be compiled into every image and developer machine, and it is ABI-coupled to the PHP minor version. PECL xhprof is effectively stale, so PHP 8.2 and 8.3 usually require the Tideways tideways_xhprof fork or a pinned build. Any PHP upgrade becomes a rebuild-and-revalidate event, which is the real integration gate rather than Composer.
- Which Laravel versions does this package support?
- None. There is no Laravel support, no service provider, no facade, and no Laravel config; the package targets Symfony only. If you port the idea yourself, Laravel 10 or 11 on PHP 8.2 or 8.3 with a compatible xhprof build is the realistic baseline. Verify compatibility against your own stack rather than assuming it.
- How would I add XHProf profiling to Laravel and send profiles to Buggregator?
- Implement a terminable middleware that starts XHProf in handle() and, in terminate(), stops it, builds the payload, and POSTs to Buggregator's xhprof ingestion endpoint using Laravel's Http facade. Gate it behind an env-driven flag such as PROFILING_ENABLED so it stays dev-only. Test it with Http::fake() so no real Buggregator server is required. The bundle's roughly 150-line core is a solid reference for the wire format.
- Is this package safe to run in production?
- Treat it as dev-time tooling only. If profiling leaks into production request paths without a kill switch, it becomes a latency and data-exposure incident. Sampled production profiling is possible, but it should be a deliberate later decision rather than the default configuration.
- Is this bundle actively maintained?
- The signals are weak: about 7 stars, zero dependents, a single maintainer, and a last release dated 2024-03-04. Buggregator server and this bundle are versioned independently with no published compatibility matrix. If you depend on it, you effectively own it.
- How does this compare to Laravel Telescope, Xdebug, or Blackfire?
- Telescope records queries, jobs, and requests but is not a sampling profiler; Xdebug is heavier and not built for streaming into a shared UI; Blackfire is a commercial platform. This bundle's niche is pushing XHProf profiles into Buggregator alongside dumps, logs, and other debugging events. If Buggregator is not already adopted by your team, this adds a second new tool to the stack.
- Should I fork this bundle or write my own Laravel package?
- Write a thin internal Laravel package: a ProfilingServiceProvider, config/profiling.php, a terminable middleware, a payload builder, and Http::fake tests, roughly 1 to 3 engineer-days including tests. Use this repository as an MIT-attributed reference for the payload schema and ingestion contract. Fork only if a Symfony service is also in your estate and you want one shared contract across both frameworks.