- Can I use halleck45/phpmetrics-collector-bundle in a Laravel application?
- No. The package is a Symfony bundle that registers a DataCollector with Symfony's WebProfilerBundle and renders a panel in the Symfony debug toolbar. Laravel has no equivalent extension point, and its debug bar (barryvdh/laravel-debugbar) wraps PHP DebugBar's DataCollectorInterface, a completely different abstraction. Every Laravel integration path means replacing the bundle's Symfony wiring rather than reusing it, so treat the repository as reference material only.
- What does this bundle actually do and what does it depend on?
- It runs PhpMetrics against your codebase, saves the generated reports in a database via Doctrine, and serves a web dashboard for tracking code quality metrics over time. It also ships console commands to collect metrics and compare trends between builds, plus a Symfony debug toolbar panel. Because it depends on Doctrine, WebProfilerBundle and Symfony2-era constraints, none of that machinery is portable to Laravel.
- Is PhpMetrics a runtime profiler or a static analysis tool?
- PhpMetrics performs static analysis: cyclomatic complexity, maintainability index, Halstead metrics, coupling and LCOM. It does not profile requests or measure runtime behaviour. Embedding it in a debug bar implies analysing the whole codebase on a request, which only works behind aggressive caching and is better served by an on-demand Artisan command or a CI job.
- Does the bundle support Laravel 10, 11 or 12 and PHP 8.2 or 8.3?
- No. The bundle carries a stale Symfony constraint set and depends on the dev-only, version-sensitive WebProfilerBundle, so it is incompatible with modern Laravel applications and current PHP runtimes. The upstream analysis engine, phpmetrics/phpmetrics, is framework-agnostic and is the piece worth checking for PHP 8.2 and 8.3 support. Pin whichever release of the engine matches your runtime in composer.json.
- How do I get PhpMetrics metrics into a Laravel project?
- Install the engine only, with composer require --dev phpmetrics/phpmetrics, and never install the Symfony bundle itself. Then add a console command such as php artisan quality:metrics that invokes the analyser against app/, src/ or your configured paths and writes JSON to storage/app/metrics/. Publish the HTML report as a CI build artifact or to GitHub or GitLab Pages, with zero framework coupling and no fork to maintain.
- How should I configure which paths PhpMetrics analyses in Laravel?
- In the bundle this lives in Symfony configuration, so there is nothing to copy over directly. In Laravel, put the paths in a config file such as config/metrics.php, gate the feature behind a metrics.enabled flag, and have the command read the path list from there. Keep the artefact keyed on git rev-parse HEAD plus a hash of the analysed files so repeated runs stay cheap.
- Can I add a PhpMetrics panel to Laravel Debugbar?
- Yes, but you must write the collector yourself: an App\Support\DebugBar\PhpMetricsCollector implementing PHP DebugBar's DataCollectorInterface, registered through the debugbar.collectors config key. Guard it behind APP_DEBUG and your metrics.enabled flag, and never analyse the codebase on a normal request. Cache aggressively on the Git SHA and file mtime hash, and confirm the exact DataCollectorInterface signature for the PHP DebugBar major you are running, because it has changed between majors.
- Will installing this bundle cause Composer dependency conflicts?
- Very likely. The old symfony/* constraints and the transitive web-profiler-bundle requirement collide with the Symfony components a modern Laravel app already pulls in. The benefit is nil because the bundle contributes little more than a reference UI. Keep symfony/web-profiler-bundle out of your application entirely and add only phpmetrics/phpmetrics as a dev dependency.
- How do I run PhpMetrics in CI and publish the HTML report?
- Add phpmetrics/phpmetrics as a dev dependency and run it as a dedicated CI step against your source directories. Publish the generated HTML as a build artifact or a GitHub or GitLab Pages target, and optionally fail the build when a quality threshold is breached. This path needs no framework integration, no forked bundle and no debug toolbar, which is why it is the recommended adoption route.
- Is this package maintained, and what should I use instead?
- Signals are weak: around 51 stars, no dependents, a stale Symfony constraint set and a low incremental-value score versus existing QA tooling. Instead, use phpmetrics/phpmetrics directly for maintainability index, coupling and complexity distribution, alongside PHPStan or Psalm for type checking, PHPMD for mess detection and GrumPHP for git hooks. If you still want a debug-bar panel, budget one to three days for a small custom collector with a clear owner and deprecation plan.