- How do I install wnx/laravel-stats and run it for the first time?
- Install it as a dev dependency with composer require wnx/laravel-stats --dev; the service provider registers itself automatically. Run php artisan config:clear first, then php artisan stats to see the component breakdown. If you want to adjust the scanned paths or register custom classifiers, publish the config with php artisan vendor:publish --provider="Wnx\LaravelStats\StatsServiceProvider". No migrations, credentials, or external services are required.
- Which Laravel and PHP versions does wnx/laravel-stats support?
- The current release line supports Laravel 12 and 13 on PHP 8.4 and 8.5. Older 2.x releases dropped support aggressively in minor versions: v2.14 dropped everything below Laravel 11 and PHP 8.2, and v2.18 dropped Laravel 11 plus PHP 8.2 and 8.3. If your fleet is still on Laravel 10 or 11 you will be pinned to an unsupported release, so check the Composer constraints before adopting it.
- What does php artisan stats actually report?
- It scans the paths defined in the config, applies classifiers to each class, and groups your codebase into Laravel component types such as Controllers, Models, Jobs, Policies, Livewire Components, and Nova Resources. Each component row reports class counts and lines of code so you can see where complexity is concentrated. Add --verbose to see exactly which classes landed in which component. Classification relies on inheritance checks plus runtime registration lookups rather than pure static analysis.
- How can I use the JSON output in CI to track architecture drift?
- Run php artisan stats --json (optionally with --verbose) in a CI job and store the output as a build artifact so you can diff codebase composition release over release. The JSON is the real integration surface: baseline it, alert on thresholds such as Controller LLOC growth or ServiceProvider count, and keep it out of the deployment critical path. Pin the package version, because LOC definitions changed in v2.1.0 and again in v2.11.2 when the metric moved to a fork, so absolute numbers are not comparable across versions.
- Does wnx/laravel-stats add runtime overhead or affect production?
- No. It is a dev-only dependency that ships a single Artisan command, with no production code path, no migrations, and no external service dependencies. It reflects over your class map only when you invoke php artisan stats. Keep it in require-dev and it never loads in production.
- Can I classify my own architectural patterns, like Repositories or Domain Actions?
- Yes. The package exposes a Classifier contract plus a custom_component_classifier config entry, so you can codify your team's own vocabulary into the same report. That turns a generic composition report into a governance check for patterns you have already agreed on. Implement the contract the same way the built-in classifiers do and register it in the published config file.
- Why are my Pest tests missing from the stats?
- Pest test files are excluded automatically because the package cannot detect them internally, as documented in discussion #194 on the repository. That makes test-related composition figures unreliable on Pest codebases, which is a growing share of the ecosystem. If test counts matter to you, either use PHPUnit or treat the test components in the report as incomplete.
- Why are some classes misclassified, and how do I verify the report?
- Classification depends on runtime registration lookups, such as policies in AuthServiceProvider, middleware in the HTTP kernel, and listeners in EventServiceProvider, so it tracks framework internals closely. Laravel 11's bootstrap refactor required a dedicated fix in v2.13.1, and non-standard layouts like modular monoliths, DDD folders, and multi-app repos are exactly where the classifier assumptions break. Breakage produces wrong numbers rather than errors, so run php artisan stats --verbose and spot-check the groupings after every Laravel major upgrade.
- What does the --share option do, and does it send data off my machine?
- The --share option implies data egress, so treat it as something that must be reviewed before it is enabled anywhere. Check whether it is opt-in in your installed version and what exactly is transmitted before turning it on in CI or on developer machines. If your policy forbids off-host telemetry, simply omit the flag and keep the JSON output local.
- Is wnx/laravel-stats well maintained, and how hard is it to remove?
- It is a small, single-maintainer package with no LTS branch and no paid support, so treat it as a reversible experiment rather than a gate. Removal is composer remove wnx/laravel-stats --dev, and because there is no production code path, uninstalling is contained to CI and developer laptops. If you want to make governance checks depend on it, plan for the maintenance risk explicitly.