- What is rajmundtoth0/phpstan-forbidden used for?
- It is a PHPStan extension for banning selected entities through static analysis, so teams can enforce an architectural or API-usage policy in CI. It is installed as a Composer require-dev package and registered through a phpstan.neon include. It is not a runtime library and does not add a Laravel service provider or container coupling.
- How do I install phpstan-forbidden in a Laravel application?
- Install it with composer require --dev rajmundtoth0/phpstan-forbidden, then add the package neon file to the includes section of your phpstan.neon. Add your ban list and run PHPStan as usual in CI. Adoption is cheap only if the project already runs PHPStan; the real work is deciding what to forbid and documenting why.
- Does phpstan-forbidden work with Laravel and Larastan?
- Yes, it is framework-agnostic by construction and should coexist with Larastan because it operates as a PHPStan rule extension rather than a Laravel package. The relevant constraints are the PHP version and PHPStan version, not the Laravel version. Treat it as a PHPStan governance plugin used by Laravel teams, not as a Laravel-specific dependency.
- Does phpstan-forbidden add runtime dependencies or affect production?
- No runtime dependency, service provider, or container coupling is expected, so its production footprint is effectively zero. The blast radius of adoption is confined to CI and static analysis. It belongs in require-dev and should not be deployed as part of the application runtime.
- Which PHPStan versions does phpstan-forbidden support?
- The technical evaluation targets PHPStan 1.x and 2.x, but the supported version matrix should be verified before adoption. Pin the exact package version rather than a caret range and check its PHPStan constraint against your current analyzer version. Because the package is tied to PHPStan internals, sequence its upgrades with PHPStan upgrades to avoid blocking the whole analyzer.
- Can I baseline or ignore phpstan-forbidden violations?
- That depends on whether each violation emits a stable rule identifier and whether the rule respects inline @phpstan-ignore or @phpstan-ignore-next-line suppression. The evaluation flags both points as due-diligence items rather than confirmed behavior. If stable identifiers exist, teams can target them in ignoreErrors and generate baselines; without them, baseline adoption is painful.
- How does phpstan-forbidden compare to spaze/phpstan-disallowed-calls?
- spaze/phpstan-disallowed-calls is the mature, widely adopted incumbent with better-documented configuration, rule identifiers, and baseline support. rajmundtoth0/phpstan-forbidden may offer a smaller config surface or better ergonomics, but that is a hypothesis until rule coverage is inspected. Gate any migration on rule-parity verification; coexistence is the lowest-risk outcome if the incumbent already covers your ban list.
- What entity types can I ban with phpstan-forbidden?
- The available evaluation does not enumerate the exact bannable entity types, so verify coverage in the README and source before relying on it. Check specifically for functions, static and instance methods, class instantiations, constants, namespaces, and properties. Coverage gaps determine whether you still need the incumbent disallowed-calls package alongside it.
- Can I customize phpstan-forbidden messages to link to an ADR?
- Whether violation messages are customizable and can carry a link to the ADR explaining each ban must be verified in the package documentation. Custom messages with rationale are valuable because the hard part of adoption is governance, not installation. Also check what happens on an unrecognized config key: a hard failure is safer than a silent no-op.
- Is phpstan-forbidden maintained enough for production CI use?
- It is low-risk at runtime because it only affects CI, but the package itself is unproven: the evaluation cites 7 stars, 0 dependents, a single author, and an anomalous last release date that needs verification against GitHub tags. Pin the exact version, confirm the license, and check maintainer responsiveness to issues and PRs before standardizing on it. A pilot-tier rollout is appropriate until rule coverage and upgrade tracking are proven.