- Is spaze/phpstan-disallowed-calls a Laravel package?
- No. It ships no service provider, config file to publish, or runtime code. It is a PHPStan rules extension that belongs in require-dev and your CI pipeline, where it flags configured calls during static analysis rather than at application runtime.
- How do I install spaze/phpstan-disallowed-calls in a Laravel project?
- Run composer require --dev spaze/phpstan-disallowed-calls. If phpstan/extension-installer is installed, the rules register automatically; otherwise add vendor/spaze/phpstan-disallowed-calls/extension.neon to the includes block of your phpstan.neon. Then define your disallowed functions, methods, and other symbols in the same config file.
- Does it work with Larastan and an existing phpstan.neon?
- Yes. Larastan is PHPStan plus Laravel-aware extensions, so this ruleset composes on top of your existing phpstan.neon without touching application code. Keep your Laravel analysis paths and add the disallowed-calls configuration alongside them. You can also start from the bundled configuration files for common dangerous or loose calls.
- How do I disallow var_dump() or direct calls to a generic logger?
- Add the function names to the disallowedFunctions list in phpstan.neon, and add the logger methods to disallowedMethods with the class name. You can use the bundled configs as a starting point and then tailor rules to your own wrappers. Because analysis runs without executing code, leftover var_dump() calls are reported as errors in CI.
- Can I allow exceptions for specific files, methods, or parameter values?
- Yes. The extension supports granular re-allowing by file path, enclosing function or method, parameter value, PHPDoc typeString, flag, instanceof or interface implementation, class or method attributes, and type-hint position. That lets you keep a strict global rule while carving out legitimate exceptions instead of ignoring the whole check. The disallowExceptIn variants invert the default and short-circuit later directives, so document how your team uses them.
- Does it detect dynamic calls like call_user_func() or $fn()?
- Largely no. PHPStan rules see static syntax, so $fn(), call_user_func(), variable static calls, and container-resolved methods are mostly outside their reach. In 4.9.2, unknown functions without available reflection are also deliberately not reported to reduce false positives. Treat the rule as a hygiene gate, not full enforcement of every call path.
- Which Laravel and PHP versions does it support?
- It has no Laravel version constraint because it does not integrate with Laravel's runtime. Compatibility is driven by the PHPStan version, which in turn depends on your PHP version. The changelog tracks PHPStan-version accommodations, so pin both PHPStan and this extension in composer.json to avoid surprise breakage on updates.
- Does it add runtime overhead or belong in require-dev?
- No, it adds no runtime overhead because it is static analysis only. Install it with require-dev and run PHPStan in CI or a pre-merge check. Keep it out of production dependencies, since it is a development tool that never boots with your Laravel application.
- Is it a security control against malicious developers?
- No. The README explicitly says it is another pair of eyes for your own mistakes, not a defense against hostile developers who can obfuscate calls. Position it as code-hygiene and standards enforcement, not a security boundary. Use dedicated security review and tooling for threat modeling and adversarial code.
- What alternatives are there, and is it actively maintained?
- ekino/phpstan-banned-code is a credible alternative with different configuration ergonomics, and PHP_CodeSniffer-based rules operate at a different layer. This package is MIT-licensed and actively released, but it has a small maintainer set, so single-maintainer risk is real. Because it is dev-only and swappable, that risk is manageable if you pin versions and keep the rule config in your repository.