- What does tomasvotruba/phpstan-bodyscan actually do?
- It is a dev-only CLI tool that scans PHP class bodies and reports type-declaration coverage for parameters, return types and properties. Instead of enforcing correctness at a fixed PHPStan level, it quantifies how far your codebase is from the next level and produces a work queue. It uses PHPStan's parser and reflection layer under the hood. Treat it as a code-quality instrument for developer productivity, not an application dependency.
- Is phpstan-bodyscan still maintained, or is it deprecated?
- The package is marked deprecated, so you should not start new adoption on it. It was a single-maintainer tool from Tomas Votruba, who is prolific and credible, but the bus factor is one. Existing users should plan an exit path toward native PHPStan level ratcheting, baselines and strict rules. Check the repository for the recommended replacement before adding it to a pipeline.
- How do I install phpstan-bodyscan in a Laravel project?
- Install it as a Composer dev dependency so it never reaches production: composer require --dev tomasvotruba/phpstan-bodyscan. There is no service provider, no facade and no config file to publish, because it is not a Laravel package in the framework sense. It runs as a peer to phpstan, pint, rector and php-cs-fixer in the same CI stage. Pin the exact version, since the project is pre-1.0 and minor bumps may break things.
- Does phpstan-bodyscan work with Laravel 9, 10 and 11?
- It has no version coupling to the Laravel framework, so it works across Laravel 9 through 11 as long as your PHP version satisfies the package constraint. It is a standalone CLI that walks your source files rather than a framework integration. Confirm the PHP matrix across your dev containers and CI image before rollout. There is zero runtime footprint, zero deploy risk and no container or infrastructure change required.
- How is bodyscan different from PHPStan or Larastan?
- PHPStan enforces correctness at a configured level, and Larastan adds Laravel-aware rules and stubs on top of it. Bodyscan does not replace either; it complements them by measuring type-declaration coverage and showing how much work separates you from the next level. It is a poor fit if PHPStan is not already adopted, because it adds a second static-analysis surface without a foundation. The strongest fit is teams already standardized on PHPStan who want a ratchet-don't-big-bang modernization path for legacy code.
- Can I use the --json output to gate CI builds?
- Version 0.2.0 added a --json flag that turns the human-readable report into a machine-consumable metric, which is what makes the tool governable by a platform team. A recommended sequence is to first run it non-blocking, upload the JSON as an artifact and establish history, then add gating once you have a baseline. Be careful: the JSON schema ships without a stated stability contract, so any dashboard must tolerate schema drift. Record a sample payload and treat it as your de facto contract.
- Does bodyscan hit memory limits on large codebases?
- Version 0.2.0 raised the default memory limit, which removes the most common operational blocker on large monorepos and big app/ trees. That change is purely permissive and reduces the need for per-job php -d memory_limit overrides in CI config. Ask the maintainer whether the new default overrides php.ini and --memory-limit or defers to them. Capture runtime and memory behavior on your largest repository during a spike before committing to a schedule.
- Will bodyscan conflict with my pinned phpstan/phpstan version?
- Dependency surface overlap is the most likely integration failure, because bodyscan pulls PHPStan-adjacent packages and accepts specific ranges for phpstan/phpstan and nikic/php-parser. Budget roughly half a day for a dependency-resolution spike on your largest repo before touching the main CI pipeline. Validate in a scratch branch first and confirm no lockfile conflict with your existing PHPStan pin. Check the changelog for the exact accepted version ranges per release.
- Is it safe to depend on a pre-1.0 package like this?
- At 0.x, minor version bumps may contain breaking changes, so pin exactly and review every changelog entry. That is acceptable for a dev-only tool that never runs in production, but not for anything on the critical path. Two changes in 0.2.0, the higher memory limit and --json output, are additive relative to 0.1.2 and non-breaking. Keep the dependency isolated to require-dev so it can be removed without touching application code.
- What should I use instead now that bodyscan is deprecated?
- The safest replacement is native PHPStan level ratcheting with a generated baseline, plus phpstan-strict-rules and, for Laravel codebases, Larastan. Rector and php-cs-fixer cover the automated refactoring and style side of the same modernization effort. If you need per-directory metrics, shard your PHPStan runs and track error counts per path over time. Evaluate any successor tool the same way: dev-only dependency, pinned version, non-blocking CI job first, and gating only after a baseline exists.