Phpstan Disallowed Calls Laravel Package

Product Decisions This Supports

• Enforcing engineering standards without code review heroics. The package turns house rules ("never call var_dump()", "always go through our logger", "don't touch $_REQUEST", "no eval/extract") into automated CI gates via PHPStan. That converts a policy document into a build-breaking check, which is the single cheapest lever a PM has for raising quality without adding headcount or process.
• Build vs. buy for custom static-analysis tooling. Any roadmap item phrased as "we should build a linter to catch X" should be evaluated against this first. It already covers functions, methods, static calls, constants, class constants, namespaces, attributes, enums, instance/static/enum properties, keywords/control structures (else, goto, declare), superglobals, and PHP's own disable_functions / disable_classes lists. That is a broad, config-driven surface area for a composer require --dev.
• Migration and deprecation roadmaps. Disallowed-namespace rules plus the allowInTypeHintPositions option let you forbid direct use of a legacy namespace or class while grandfathering type declarations — a practical way to draw a boundary around a module you intend to strangle, and to track how much code still reaches across it.
• Security/compliance hardening as a shippable milestone. The dangerous bundled config flags things like phpinfo() (which can leak session IDs) and shell-execution functions. This is scope you can put on a security workstream and demo, rather than a vague "reduce risk" line item.
• Onboarding and API-surface governance. Re-allow directives (allowInPaths, allowInMethods, allowInInstanceOf, allowInClassWithAttributes, parameter/flag conditions) express institutional knowledge: "only the Sanitizer class may call htmlspecialchars directly." That encodes architecture decisions in config rather than in tribal memory, and makes exceptions reviewable in a PR.
• Framework/stack alignment. Symfony and Nette have maintained companion configs, so a PM can scope adoption to an existing stack without a research spike. Third-party or legacy code can also be analyzed with a custom ruleset running this extension alone, which supports due-diligence and vendor-audit use cases.
• Roadmap risk sizing. Version history shows steady, active maintenance through v4.x (properties, enums, attributes, error identifiers, config schema validation) with a release cadence that extends into 2026. That is a signal that a PM can safely plan multi-quarter work on top of it.

When to Consider This Package

Adopt when most of the following hold:

• You already run PHPStan (or are about to) in CI. This is an extension, not a standalone tool — it is worthless and uninstallable without PHPStan as a prerequisite.
• You have codified, non-negotiable house rules that a human reviewer keeps having to repeat — debug output left in, wrong logger, direct superglobal access, banned crypto/hashing functions, forbidden control flow.
• You need exceptions, not a blunt blocklist. The differentiator here is the allow/re-allow matrix: paths, methods, parameter values, flags, instanceof, attributes on classes/methods, and type-hint positions. If your policy is just "ban these five functions globally," a simpler banned-code rule gets you 90% there with less config surface.
• You want to bound a legacy area. Namespace/class disallowing plus type-hint exemptions is the strongest fit for migration guardrails.
• Someone on the team owns the config. Bundled configs reduce setup cost, but custom rules and the allow-precedence semantics (allowExceptIn* stops evaluation of later directives; a config entry replaces prior entries for the same item) have real learning curve. Plan for a named owner, not a fire-and-forget install.
• You accept "poka-yoke, not sandbox." The README is explicit that this does not defend against hostile developers and can be bypassed via obfuscation. If the requirement is security enforcement against insiders, this is the wrong control.

Look elsewhere or de-scope when:

• You are not on PHPStan (e.g., Psalm/PHP_CodeSniffer/PhpCsFixer-only shop). Either migrate or pick a tool native to your analyzer; adding PHPStan only for this is usually unjustifiable.
• You need to ban by pattern/regex across arbitrary syntax. Coverage is what the test suite covers; anything untested "might be, but most probably will not be" detected. Treat the feature list as the spec, not PHP's grammar.
• You need guaranteed detection of dynamic dispatch. Release 4.9.2 notes that unknown functions (reflection unavailable) are no longer reported. Dynamic/call_user_func-style indirection will have gaps — accept that as a known limitation in your threat model.
• Your only need is a one-off audit of a third-party codebase and you don't want another dev dependency in composer.json. The "no other rules" custom-ruleset mode makes this viable, but weigh it against a manual grep for a one-time job.
• The rules would be unmaintainable by your team — long allow-lists are a smell that the underlying architecture, not the linter, needs the fix.

Watch items to flag before committing: 0 dependents on record despite 346 stars — popularity is real but downstream adoption is thin, so you are an early-ish adopter in dependency terms; MIT license is fine for commercial use; case-insensitivity is inconsistent by design (function/method/class/namespace names ignore case; constants, files, paths do not) which will confuse rule authors; error identifiers and config-schema validation changed in v3.0.0 with possible BC breaks, so pin versions and read changelogs before minor bumps.

How to Pitch It (Stakeholders)

For executives — one slide:

We can make a category of code-review comments disappear from our process at essentially zero cost. This is a free (MIT), actively maintained PHPStan add-on that fails the build when someone uses a function, class, or language feature we've decided we don't want. It is a composer require --dev, one config file, no runtime dependency, no production code change, no vendor lock-in. It converts rules we already agree on — no debug output, only our logger, no raw superglobals, no deprecated namespaces — from "please remember" into "CI says no." It also gives us a clean, measurable way to wall off legacy code during the migration. Recommendation: adopt for the next sprint as a CI gate, scoped to 5–10 rules with a named owner.

For engineering leadership — the argument in three points:

1. Cheap to try, cheap to abandon. Dev-only dependency, MIT-licensed, no runtime footprint, removable in one commit. The cost is configuration and a small amount of reviewer time to arbitrate the allow-list.
2. High-leverage placement. It plugs into the static analysis we already run, so findings arrive at PR time, before review, from a check that never gets tired. Enforcement of standards stops depending on which senior engineer is on rotation.
3. Encodes decisions, not just bans. The allow-in-path / allow-in-method / allow-with-parameters / allow-in-instanceof directives mean we can say "only the Sanitizer may call this" — architecture captured in version-controlled config and diffable in code review, instead of in a wiki page nobody reads.

For the engineering team — the honest caveats:

• This is a guardrail against our own mistakes, not a security boundary. The README says so; we should not let a green build be mistaken for a security guarantee.
• Detection is limited to what the rule set and test suite cover; obfuscation and some dynamic calls will slip through. Budget for one iteration to tune rules and noise.
• Someone must own the config. Allow-lists rot; review them quarterly or they become a second, worse blocklist.

Ask: two engineer-days over one sprint — half a day to install and adopt bundled configs, one day to codify our top rules and exceptions, half a day to clear baseline findings — plus a named owner and a place in the definition of done. Success metric: reduction in repeated review comments of the "please remove var_dump / use our logger" class, and a stable rule count that stops growing after the first month (growth after that means the rules, not the code, need revisiting).