Phpmetrics Collector Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — there is no service provider and no php artisan integration. Treat the assessment below as "how to get value from this in a day-to-day workflow," which for a Laravel developer usually means either (a) using it inside a Symfony service you maintain, or (b) mining it as a reference implementation for a Laravel Debugbar panel.

Minimal steps in a Symfony host app:

1. Install as a dev-only dependency:

   composer require --dev halleck45/phpmetrics-collector-bundle
   

2. Register the bundle in config/bundles.php (Symfony 4+) or AppKernel.php (Symfony 2/3), guarded by the dev/test environment.
3. Ensure APP_ENV=dev and APP_DEBUG=true so the WebProfilerBundle toolbar renders. The collector piggybacks on the profiler.
4. Load a normal HTML route and open the profiler; look for the PhpMetrics panel in the toolbar, then drill into the profiler page.

Where to look first:

• The bundle's DependencyInjection/ folder for the config tree (what can be toggled).
• Its DataCollector class — that's the integration point and the most reusable piece if you port the idea to Laravel.
• The Resources/views/ templates for the toolbar/profiler panel markup.

First real use case: hit a controller action in dev, open the profiler, and read the metrics for the code paths involved in that request — maintainability index, complexity, class-level smells — instead of waiting for a full phpmetrics CLI run. It's a fast feedback loop while refactoring a single feature.

Implementation Patterns

Dev-only, request-scoped analysis. The value is the "click a page, see the metrics for what that page touched" loop. Keep it strictly in dev; never register it in prod, and gate the config with %kernel.debug%.

Bundle + CLI pairing. Use the bundle for interactive spot-checks during feature work and phpmetrics --report-html=build/metrics in CI for the authoritative, whole-project report. They answer different questions: the bundle is "what did this request exercise," the CLI is "what does the codebase look like."

Probe-by-route. Pick representative routes (one heavy controller, one API endpoint, one form submission) and treat them as sampling points. Refactor, reload, compare the panel. This is far more actionable than staring at a 40-file CLI report.

Custom collectors. The cleanest extension pattern mirrors Symfony's DataCollectorInterface: subclass the bundle's collector (or register your own) to attach project-specific numbers — e.g., query count, cache hits, domain-service invocation depth — to the same panel. Register it with the data_collector tag and a unique id.

Porting to Laravel. Since you can't use the bundle directly, reuse the pattern: add a php-debugbar collector or a small middleware that runs the PhpMetrics library against the classes in the resolved controller/action, then push the result into the Debugbar's messages/custom tab. The bundle's collector class is a good reference for which metrics are cheap enough to compute per-request.

Polyglot escape hatch. If you maintain any Symfony service alongside your Laravel app, install it there and use the two side by side — same PhpMetrics vocabulary, different runtime.

Gotchas and Tips

• Abandonment risk. 51 stars, 0 dependents, and a Symfony 2/3-era lineage mean old constraint ranges. Expect to need composer require --dev --ignore-platform-reqs or a fork for modern PHP. Pin the version and don't ship it as a runtime dependency.
• Runtime ≠ static. The panel reflects what the request exercised; phpmetrics CLI reflects the whole tree. A "clean" panel does not mean a clean codebase, and a scary panel number can be an artifact of one hot path. Don't use it as a quality gate.
• Toolbar visibility. The WebProfiler toolbar only renders on HTML responses with a </body>. AJAX, JSON, and streamed responses won't show it — use the profiler URL (/_profiler) directly to inspect those requests.
• Config caching. After changing bundle config, run bin/console cache:clear. A stale container is the usual cause of "the panel disappeared."
• Performance in dev. Metrics collection adds overhead per request. If your dev loop feels slow, disable the collector (config flag) and re-enable when you actually want to measure — don't just live with it.
• Class-name drift across versions. The bundle has changed namespaces over its lifetime; don't hardcode collector IDs in your own code. Reference the data_collector tag id and read the profiler's registry.
• Extension point worth copying. The collect(Request, Response, Exception) signature and the getTemplate()/getName() contract are the reusable bits. If you build a Laravel equivalent, keep that shape — it maps cleanly onto Debugbar's collector interface.
• No Laravel support, no plans. If you want this in Laravel, budget for building it yourself around the PhpMetrics library; the bundle is a blueprint, not a dependency.