Php Project Analyzer Bundle Laravel Package

Technical Evaluation

Architecture fit: Poor as packaged, and the mismatch is structural rather than cosmetic. Despite framing this as a Laravel/PHP package, jdlabails/php-project-analyzer-bundle is a Symfony Bundle — it ships a Bundle class plus container service definitions intended to be registered in config/bundles.php and wired through Symfony's DI container, parameter bag, and event system. Laravel has no Bundle concept; integration requires translating the bundle's service definitions into a ServiceProvider, reimplementing configuration binding (Laravel config/*.php vs Symfony Configuration trees), and resolving any Symfony-component coupling (Console, Finder, Yaml, DependencyInjection). Depending on how much of the analysis logic lives in the bundle versus the underlying PhpProjectAnalyzer library, this could range from a half-day adapter to a partial rewrite.

Integration feasibility: Low-to-moderate. The realistic path is not installing the bundle, but targeting the underlying jdlabails/php-project-analyzer library directly and writing a thin Laravel service provider — or, more likely, invoking it as a standalone CLI in CI. Before any commitment, confirm whether the bundle contains meaningful logic or is a pure wiring shim; if the latter, the bundle is disposable and only the engine matters.

Technical risk: High, and concentrated in three places.

1. Abandonment. Last release 2018-04-15 — roughly seven PHP minor versions of drift (7.1/7.2 era through 8.3/8.4). Expect composer.json platform constraints (php: ^7.0, old symfony/* ranges, pinned nikic/php-parser or symfony/finder) that hard-conflict with a modern Laravel dependency graph. AST-parser pins are the most common blocker, since php-parser is also pulled in transitively by static-analysis tooling.
2. Supply chain. No release in seven years implies no security response process, no CI, no disclosed vulnerability handling. For a tool that is expected to inspect our source code, this still executes third-party code in our pipeline — it must run sandboxed and read-only.
3. Adoption signal. 11 stars, 0 dependents, single-maintainer bus factor of one. There is no community to validate correctness of the metrics or absorb maintenance. Any defect we hit is ours to fix.

Key questions:

• Does the bundle contain analysis logic, or only Symfony wiring around an external library?
• What does the engine actually compute — cyclomatic complexity, coupling/afferent-efferent, duplication, dead code? Can we get the same signal from tools we already run (PHPStan/Psalm, PHPMD, Deptrac, php-cs-fixer)?
• What are the exact composer.json constraints, and does the engine resolve against our current PHP and Laravel versions?
• Is the project's license compatible with forking/vendoring into our namespace?
• Who owns the output — is this a CI gate (blocking merges) or an advisory dashboard? That determines whether correctness bugs are tolerable.

Verdict: Do not adopt the bundle as a dependency. Evaluate the underlying engine as a 1–2 day spike; if it earns its place, fork it in-house rather than depend on it.

Integration Approach

Stack fit: Assumes a Laravel application on PHP 8.x. The bundle will not autoload into that stack without modification. Two viable shapes:

• CI-side CLI (recommended): Run the analyzer as a standalone, isolated step in the pipeline — its own container, its own lockfile, no shared dependency graph with the application. This sidesteps composer constraint conflicts entirely and keeps an unmaintained package out of the app's runtime surface. Output: a JSON/HTML report artifact, optionally gated by thresholds.
• In-app service (not recommended for v1): A Laravel ServiceProvider binding the engine, plus a config file and an artisan command. Only justified if we need on-demand analysis from the application itself — a rare requirement for a project-quality tool.

Migration path: No migration — this is net-new instrumentation. The practical sequence is: confirm the engine's dependency resolution in an isolated Composer project → run it against one representative Laravel repo → diff its findings against PHPStan/PHPMD output → decide fork vs replace.

Compatibility: Expect to pin the fork to modern PHP ourselves. nikic/php-parser is the highest-probability breakage point; a 2018 analyzer will target the v3/v4 AST API, and v5 changed node structures. Budget for an upgrade pass on the fork — this is the single largest unknown in the estimate.

Sequencing:

1. Week 1 — Spike. Isolated project, resolve dependencies, run against a sample repo, capture findings quality and false-positive rate.
2. Week 2 — Decision. If signal is genuinely additive: fork to internal/php-project-analyzer, bump PHP and parser constraints, add CI. If not: standardize on PHPStan + PHPMD + Deptrac and close the evaluation.
3. Week 3–4 — Pipeline integration. Containerized CI step, report artifact, threshold policy, baseline of current scores.
4. Ongoing — Ratchet. Fail builds only on regression versus baseline, not absolute scores, to avoid a wall of pre-existing findings blocking the team on day one.

Operational Impact

Maintenance: The dominant cost. We inherit the entire maintenance burden the moment we fork — PHP version bumps, parser API upgrades, rule correctness, false-positive triage. Realistically 2–5 engineer-days per year of steady-state upkeep plus a spike each PHP major. There is no upstream to send patches to in any meaningful sense; assume zero responsiveness.

Support: None. No maintainer SLA, no issue triage, no documentation beyond the README. Internal ownership must be named explicitly before adoption — an unowned analysis tool in CI becomes a broken build everyone routes around.

Scaling: Compute cost is a real but manageable factor. Per-file AST parsing on a large Laravel codebase runs minutes, not seconds. Mitigate with incremental analysis (changed files only on PRs, full sweep nightly) and caching keyed on file hash. Parallelize per-directory if the engine supports it; assume it does not and plan a shard-by-path wrapper.

Failure modes:

• Silent no-op — analyzer parses nothing due to an unhandled PHP 8 syntax node and reports a perfect score. Highest-severity risk: false confidence. Mitigate with a canary file containing known violations, asserted on every run.
• Dependency rot — a transitive pin blocks an unrelated upgrade in the CI image; discovered mid-release.
• False-positive flood — noisy rules erode trust and the gate gets disabled, often permanently.
• Unpatched execution risk — unmaintained code running over our source in CI; isolate in a container with read-only mounts and no secrets.
• Bus factor — original author unreachable; we cannot upstream fixes.

Ramp-up: Low for consumption (a CI step and a report), moderate for ownership (must understand the AST visitor set and metric definitions to judge correctness). The real ramp-up cost is interpretation — a TPM needs agreement on which metrics drive decisions before the numbers arrive, or the report becomes shelfware. Recommend a single owner, a documented threshold policy, and a 30-day trial with an explicit keep/kill review.