Php Project Analyzer Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for code-health instrumentation. This bundle is a thin Symfony integration layer around PhpProjectAnalyzer, so it answers a narrow question: do we assemble our own static-analysis/quality-reporting pipeline, or adopt an existing analyzer and adapt it? It does not answer "should we invest in code quality tooling" — that decision is already made by the time you evaluate it.
• Tech-debt visibility in the roadmap. A project analyzer produces the kind of metrics (complexity, coupling, class/dependency structure) product managers use to justify a hardening or refactoring sprint, or to argue that a "quick" feature request carries disproportionate risk. The bundle's job is to make those metrics available inside a Symfony app's own console/DI context — useful if you want in-app quality reporting rather than a separate CI artifact.
• Architecture governance as a platform capability. If your platform team wants repository-level structural rules (no cross-module dependencies, no god classes) surfaced to engineering leadership, integration bundles are the "last mile" work between a raw analyzer library and a team-usable tool.
• Roadmap signal on framework strategy, not features. The package is tagged as a Symfony Bundle, not a Laravel package. Despite the "Laravel/PHP" framing, nothing here is Laravel-native — there are no service providers, no config/*.php publishing, no facade. If your roadmap assumes a Laravel-first stack, this is a data point that the ecosystem around this analyzer is Symfony-oriented and you would be porting integration glue yourself.
• Vendor/OSS dependency risk review. Zero dependents and a last release of April 2018 is itself a decision input: adopting it means accepting an unmaintained dependency, which for a quality tool is a particularly awkward contradiction.

When to Consider This Package

Consider it only when all of the following hold:

• You are on Symfony (not Laravel), and you specifically want the PhpProjectAnalyzer library wired into your app's container/console rather than run as a standalone binary.
• You are doing exploratory or internal analysis — a spike, a one-off audit of a legacy codebase — where the output informs a decision rather than gating a pipeline.
• You can tolerate pinning to a 2018-era dependency tree and have verified it installs cleanly against your current Symfony and PHP versions.
• You have someone who can own a fork. With 0 dependents, you are effectively the first production user; there is no community to absorb a bug report.

Look elsewhere when:

• You are on Laravel. There is no Laravel integration here. Either consume the underlying analyzer as a CLI in CI, or use PHPStan/Psalm with Larastan, which are Laravel-native and actively maintained.
• You need CI gating. A quality gate needs a maintained tool with stable exit codes and a rule/config story. PHPStan, Psalm, PHP_CodeSniffer, GrumPHP, and Deptrac (for dependency/architecture rules) are the credible choices; all are actively released and widely depended upon.
• You need a maintained SLA or security posture. Last release 2018, 11 stars, no dependents. Any CVE or incompatibility is yours to fix.
• You want metrics dashboards for stakeholders. Purpose-built options (PhpMetrics, SonarQube, Qodana) give you reporting and history without custom glue.
• The metric you actually want is dependency/coupling rules — Deptrac is a much stronger fit than a general-purpose analyzer bundle.

A reasonable read of the score (~0.46) and the metadata: technically plausible, ecosystem-wise inert. Treat it as a reference implementation to read, not a dependency to ship.

How to Pitch It (Stakeholders)

One line: A small, unmaintained Symfony wrapper around a PHP project analyzer — useful as a reference for wiring code-quality metrics into a Symfony app, but not something we should depend on in production.

To executives: This is not a build-vs-buy decision of any size. If we want tech-debt visibility for roadmap planning, the cost is roughly one engineer-week to stand up PHPStan + PhpMetrics in CI plus a monthly review cadence — using maintained tools with large user bases. This bundle would add risk (last released 2018, no downstream users) to a decision we can de-risk for free. Recommendation: do not adopt; fund the maintained-tooling path if the debt-visibility need is real.

To engineering: If you're on Symfony and want an in-app analyzer, read this bundle's source for the container/console wiring pattern, then wire the analyzer yourself or vendor a fork with a named owner. If you're on Laravel, skip it entirely — Larastan/PHPStan is the path. Either way, the gate belongs in CI, not in a bundle.

Ask: Decide whether code-health metrics are a roadmap input this quarter. If yes, approve the CI tooling spike. If no, close this evaluation — the package doesn't change the answer.