Getting Started

First, the framing: jdlabails/php-project-analyzer-bundle is a Symfony bundle, not a Laravel package. It ships no ServiceProvider, no auto-discovery, no Artisan command. You cannot composer require it into a Laravel app and expect it to wire itself up. Day-to-day, Laravel developers use this in one of two ways:

Standalone CLI (recommended) — use the underlying php-project-analyzer library/binary as a build-time tool against your Laravel source tree, invoked from Artisan or CI.
Sidecar Symfony app — stand up a throwaway Symfony skeleton that hosts the bundle when you actually want its web UI/report viewer.

Minimal steps for the sidecar path:

composer create-project symfony/skeleton:/tmp/analyzer   # pin to a Symfony/FrameworkBundle
                                                          # version compatible with the bundle
cd /tmp/analyzer
composer require jdlabails/php-project-analyzer-bundle

Then:

Enable it in config/bundles.php (Symfony Flex may not do this automatically given the package predates Flex conventions).
Find the config alias: bin/console config:dump-reference <alias> — the alias is not obviously php_project_analyzer, so dump the reference rather than guessing.
Point its source paths at your Laravel app (app/, packages/, your own src/) and exclude vendor/, storage/, bootstrap/cache/, database/migrations/.
Check bin/console list for the bundle's commands — they're typically prefixed with the bundle alias.

Where to look first, in order:

README.md on the repo — it's thin, but it tells you the required Symfony/PHP versions.
src/DependencyInjection/Configuration.php — the authoritative list of config keys and defaults.
src/Controller/ and src/Resources/config/routing.* — tells you what the web UI exposes and at what path.
The vendor/jdlabails/php-project-analyzer (or similarly named) package — the actual analysis engine lives there; the bundle is just glue.

First use case worth doing: run it once against app/ before a large refactor (e.g. extracting a domain layer), save the report, and use it as a trend baseline. Absolute numbers from this class of tool are noisy; deltas over time are what's actionable.

Implementation Patterns

Pattern 1 — Artisan wrapper around the analyzer binary. Keeps the tool inside your team's normal workflow without pretending it's a Laravel package:

// app/Console/Commands/AnalyzeProject.php
public function handle()
{
    $binary = base_path('vendor/bin/php-analyzer'); // or the path to your sidecar
    $report = storage_path('app/analysis/report-'.now()->format('Ymd-His').'.json');

    $process = new Process([
        $binary,
        '--source', base_path('app'),
        '--exclude', 'vendor,storage,bootstrap/cache',
        '--format', 'json',
        '--output', $report,
    ]);
    $process->setTimeout(600)->run();

    if (! $process->isSuccessful()) {
        $this->error($process->getErrorOutput());
        return self::FAILURE;
    }
    $this->info("Report written to {$report}");
    return self::SUCCESS;
}

Pattern 2 — Regression gate in CI. The highest-value use. Don't gate on absolute scores; gate on change vs. the last committed baseline.

# .github/workflows/quality.yml
- name: Analyze
  run: php artisan analyze:project --output=build/analysis.json
- name: Compare to baseline
  run: php scripts/compare-metrics.php build/analysis.json analysis/baseline.json
  # fail if cyclomatic complexity or coupling regressed > 5%

Commit the baseline JSON; update it deliberately in refactor PRs so the diff is reviewable.

Pattern 3 — Scheduled drift tracking. Nightly job writes a JSON snapshot to a metrics table (or S3), then a small dashboard charts LOC, average complexity, and coupling per module. This is where the tool earns its keep — you see the module that quietly became the worst offender.

Pattern 4 — Scoped analysis per module. Run separate analyses for app/Domain, app/Http, and each packages/* directory so a hot spot in one module doesn't get averaged away by a large clean one. Parallelize with Process::start() if the runs are slow.

Pattern 5 — Sidecar service in docker-compose. Mount the Laravel repo read-only into a Symfony container that hosts the bundle's UI:

analyzer:
  build: ./docker/analyzer          # Symfony skeleton + bundle
  volumes:
    - ./:/src:ro
  ports: ["127.0.0.1:8081:8000"]    # loopback only — see Gotchas
  environment:
    ANALYZER_SOURCE: /src/app

Pattern 6 — Layer with tools you already trust. This bundle gives you cohesion/coupling/complexity heuristics. It is not a type checker or a dependency-architecture enforcer. Pair it with PHPStan/Larastan (correctness), Deptrac (layer boundaries), and Pint (style). Treat the analyzer as the "shape of the codebase" report, nothing more.

Pattern 7 — Custom analyzers (sidecar only). The bundle's extension point is Symfony's tag system: implement the engine's analyzer interface, register it as a service, and tag it with whatever tag the bundle uses (bin/console debug:container --tag=<tag> to discover it). You can add project-specific rules — e.g. "flag controllers over 200 LOC" — and they'll appear in the same report.

Gotchas and Tips

Version reality check. Last release 2018-04-15, 11 stars, 0 dependents. That's a Symfony 3.4/4.x-era codebase targeting PHP 7.1/7.2. On PHP 8.x it will very likely fail to install or fatal on deprecated constructs. If you must run it, do it in a pinned container (php:7.4-cli) and keep it out of your application's composer.json entirely.
Never composer require this in a Laravel app. Dependency conflicts with Laravel's Symfony components (HttpFoundation, Console, Routing) are almost guaranteed, and you'll get no benefit since the bundle's wiring is kernel-level.
Zero community support. No security patches, no issue triage, no PHP 8 upgrades. Treat it as a vendored, frozen tool. If the analysis becomes load-bearing for your team, budget for replacing it with phpmetrics or PDepend, both of which are actively maintained and have first-class CLI/JSON output that drops straight into the CI pattern above.
Laravel false positives. Facades, __call/__get magic, Eloquent dynamic attributes, and container-resolved dependencies all look like "hidden coupling" or "unstable dependencies" to a static analyzer. Expect a noisy first report; calibrate by comparing Laravel module vs. Laravel module, not against absolute thresholds.
Xdebug off. If Xdebug is loaded (common in local PHP images), analysis can be 5–20× slower. php -n or XDEBUG_MODE=off before running.
Memory. Large app/ trees plus generated code will blow the default 128M. Set memory_limit=-1 in the analyzer's PHP config, and always exclude vendor/ — analyzing vendor is how people conclude the tool is slow and useless.
The web UI serves source code. The bundle's report pages show file contents and paths. Bind to 127.0.0.1, never expose it, and never deploy it to a shared/staging environment. If you want a hosted report, export JSON and render your own view.
Config key discovery. Don't guess the alias. bin/console config:dump-reference (run from the sidecar app) prints the exact tree and defaults. Similarly, bin/console debug:router | grep -i analyz finds the UI route.
Bundle template overrides. If you need the report to include your own branding or links, Symfony's bundle override convention applies: place a matching Twig file under templates/bundles/<BundleName>/... in the sidecar app. This is the cheapest customization point.
Baseline hygiene. Store reports as JSON (not HTML), keyed by git SHA, and diff them programmatically. HTML reports are for humans once; JSON is what makes the tool useful in a loop.
When to walk away. If setup costs more than two hours, stop. phpmetrics --report-json plus a 50-line comparator script gives you 80% of the value with none of the maintenance risk — and the remaining 20% (cohesion metrics, coupling graphs) is available from PDepend, which is still maintained.

Php Project Analyzer Bundle Laravel Package

Getting Started

Implementation Patterns

Gotchas and Tips