Product Decisions This Supports
- Engineering-health visibility as a roadmap input. PhpMetrics produces maintainability index, cyclomatic complexity, Halstead metrics, and class-coupling scores. Surfacing those in the debug toolbar turns "we think this module is rotting" into a number a PM can put next to a refactor epic. It supports the decision to fund or defer tech-debt work.
- Build vs. buy for internal developer tooling. This is a ~thin integration layer over an existing OSS analyzer, MIT-licensed. It answers "do we build an internal quality dashboard?" with "not yet — wire up what exists first, instrument, then decide if we need more."
- Scoping refactor spikes. When a feature request keeps slipping in one area of the codebase, per-request complexity data gives you a defensible reason to carve out a hardening sprint instead of arguing from anecdote.
- Onboarding and code-review calibration. New engineers see objective complexity signals on the pages they're working in, which shortens the "which parts are dangerous to touch" conversation.
- Explicitly not supported: release gating, regression detection, or trend reporting. This package renders a snapshot in a dev toolbar. It has no history, no thresholds, no CI output. Don't let it be sold as a quality gate.
Important caveat for a Laravel shop: this is a Symfony bundle built on WebProfilerBundle and the Symfony debug bar — not a Laravel package. It will not drop into a Laravel app. The transferable asset is PhpMetrics itself (framework-agnostic CLI/static analysis), not this bundle. For Laravel, plan on PhpMetrics in CI plus a custom or third-party debugbar panel; treat this repo as a reference implementation rather than a dependency.
When to Consider This Package
Adopt it when all of the following hold:
- The application is Symfony, not Laravel or framework-agnostic PHP.
- PhpMetrics is already (or is about to be) part of the local/CI workflow — otherwise this bundle has nothing to display.
- The audience is developers in
dev environment only; it carries no production surface.
- You want zero-config, zero-cost visibility and are comfortable with a small, low-activity OSS dependency.
Look elsewhere (or skip) when:
- You're on Laravel. No path without forking; the debug bar abstractions differ.
- You need trending, dashboards, or PR annotations. Requirements point to PhpMetrics in CI + a reporting layer (SonarQube, Codecov, Grafana, or a small internal service), not a debug toolbar.
- You need quality gates. Use PhpMetrics' violation/threshold rules in the pipeline instead.
- Dependency-risk tolerance is low. 51 stars, 0 dependents, and a low opportunity score are real signals: near-zero ecosystem validation and unclear maintenance cadence. Don't make it load-bearing. Pin it, keep it dev-only, and be ready to vendor or drop it.
- You already have PHPStan/Psalm + a metrics pipeline. Overlapping value; the incremental insight is small.
How to Pitch It (Stakeholders)
For executives (one line): A free, MIT-licensed developer-only add-on that shows code-complexity data inside the Symfony debug toolbar — it costs nothing, ships nothing to production, and gives engineering better evidence when asking for refactoring time. It is a convenience, not a platform investment.
For engineering leadership: Low-risk, dev-only, no runtime footprint in prod. It reduces the friction of "should we touch this file?" from a Slack thread to a glance at the toolbar. Caveat clearly stated: it's a Symfony bundle with a small community and no dependents, so treat it as a nice-to-have with an exit plan — pin the version, keep it out of the critical path.
For engineering (the honest framing): If you're on Symfony and already run PhpMetrics, this is a 10-minute win. If you're on Laravel — which we are — this package is not for us; the real recommendation is to adopt PhpMetrics in CI and, if we want in-request visibility, build a small Debugbar panel against its output. That's a ~1-day spike, and it's the version of this idea that actually fits our stack.