Php Code Browser Laravel Package

Getting Started

PHP_CodeBrowser is a CLI reporting tool, not a Laravel package — there is no service provider, config file, or facade. You wire it into your project as a dev dependency and point it at QA output XML plus your source tree.

1. Install as a dev dependency:

   composer require --dev zerkalica/php-code-browser
   

   The entry point is vendor/bin/phpcb.

2. Generate at least one supported input artifact. Coverage is the most common first use case:

   php artisan test --coverage-clover=build/logs/clover.xml
   

3. Run the browser against your source and the logs directory:

   vendor/bin/phpcb \
     --log build/logs \
     --source app \
     --output build/browser
   

4. Open build/browser/index.html in a browser. You'll get a directory tree of your app/ files with syntax highlighting and inline red markers where coverage is missing (or where PHPCS/PHPMD flagged issues, if those reports are also in build/logs).

Where to look first:

• vendor/bin/phpcb --help for the exact flags in this version.
• vendor/zerkalica/php-code-browser/src/ — the Application/Plugins and Application/Plugins/Reader folders show which report formats are supported.
• Your generated XML in build/logs — confirm the file paths inside the XML match the paths you're passing to --source, or nothing will highlight.

Implementation Patterns

One-shot "quality dashboard" via a Composer script.

"scripts": {
  "qa:report": [
    "@php artisan test --coverage-clover=build/logs/clover.xml",
    "vendor/bin/phpcs app --report=checkstyle --report-file=build/logs/checkstyle.xml",
    "vendor/bin/phpmd app xml build/logs/phpmd.xml cleancode,codesize,design",
    "vendor/bin/phpcb --log build/logs --source app --output build/browser"
  ]
}

Any reader that writes into build/logs gets picked up automatically because --log is a directory scan, not a single file argument. That's the main "extension point" you get without forking.

CI artifact pattern. In GitHub Actions or GitLab CI, run the same script and upload build/browser as an artifact. Reviewers click through coverage without cloning. Keep the report ephemeral:

- run: composer qa:report
- uses: actions/upload-artifact@v4
  with:
    name: code-browser
    path: build/browser

Local browsing. Serve the static output with PHP's built-in server — the report is plain HTML/JS/CSS, no routing or Laravel involvement:

php -S 127.0.0.1:8080 -t build/browser

Scoped reports for large apps. Pointing --source at the whole app/ can be slow and produces a big tree. Prefer one report per bounded context (e.g. app/Modules/Billing) when you want a focused review before a PR, and regenerate the full tree only in CI.

Exclusion discipline. Pass --exclude for vendor, storage, bootstrap/cache, and generated files, and keep build/ out of version control. A build/.gitignore with * keeps things tidy.

Gotchas and Tips

• Abandoned upstream. Stars and dependents are near zero; the package is a Composer repackaging of the older theseer/phpcb tool. Pin an exact version in composer.json and verify it installs cleanly on your PHP minor version before relying on it in CI.
• --source must match XML paths. Coverage/checkstyle files record absolute or project-relative paths. If you run PHPUnit from a subdirectory or use a different root than what you pass to --source, the annotations silently fail to appear. Run all tools from the project root.
• --log is a directory, not a file. Passing a single XML file as --log will produce an empty or partial report. Create build/logs first and drop every tool's XML in there.
• Memory limits. Coverage clover for a mid-size Laravel app easily exceeds the CLI default. Use php -d memory_limit=1G vendor/bin/phpcb ....
• Not route-integrated. There is no middleware, controller, or route helper. Don't try to mount the report inside a Laravel route — either serve the static directory separately or copy it to public/ in a throwaway build.
• Format drift is your biggest risk. Newer PHPUnit and PHPCS releases change their XML schemas. If annotations stop rendering after a tool upgrade, diff an old and new report and confirm the reader still recognizes the root element. Clover and checkstyle are the most stable inputs; PHD/PMD formats are less forgiving.
• No config file. Everything is flags. Wrap the invocation in a Composer script or Makefile rather than repeating a long command line.
• Extending it means forking. Adding a new report reader requires touching src/Application/Plugins/Reader/ and re-declaring the plugin in the application bootstrap. For a Laravel-idiomatic alternative, generate the same XML set and render a custom Artisan command or Blade view — you'll get the same highlighting with far less dependency risk.