Phpstan Disallowed Calls Laravel Package

Product Decisions This Supports

• Enforcing Code Quality & Security Standards: Integrate stricter static analysis into CI/CD pipelines to block deprecated, insecure, or non-compliant API calls (e.g., file_get_contents in production, legacy mysql_* functions). Aligns with shift-left security and compliance (e.g., PCI, GDPR).
• Developer Experience (DX) Trade-offs: Balance automation with flexibility—allowlist exceptions for legacy systems or third-party dependencies without disabling the rule entirely. Reduces toil for devs while maintaining guardrails.
• Roadmap Prioritization:
  • Phase 1: Audit existing codebase for disallowed calls (e.g., eval(), dynamic function calls) to identify tech debt.
  • Phase 2: Enforce rules in new PRs via GitHub Actions/PHPStan baseline, with opt-outs for approved exceptions.
  • Phase 3: Extend to vendor packages (e.g., block str_replace in security-sensitive modules).
• Build vs. Buy:
  • Buy: Avoid reinventing static analysis rules (e.g., custom PHPStan extensions). This package provides maintainable, community-vetted rules with minimal setup.
  • Build: Only if needing highly specialized disallow lists (e.g., internal APIs) not covered by the package’s extensibility.

When to Consider This Package

• Adopt if:
  • Your team uses PHPStan (or plans to) for static analysis.
  • You need to block specific functions/methods (e.g., create_function, call_user_func_array with dynamic args) due to security or architectural constraints.
  • You require granular allowlists (e.g., permit json_encode in API handlers but block it elsewhere).
  • Your codebase has legacy cruft or third-party dependencies with disallowed calls that need phased removal.
• Look elsewhere if:
  • You’re not using PHPStan (this is a rule extension, not a standalone tool).
  • Your needs are dynamic (e.g., runtime call blocking)—use a proxy layer (e.g., Laravel middleware) or runtime security tools (e.g., PHPStan’s disallowedTypes for arguments).
  • You lack developer buy-in for static analysis; this requires cultural shift to treat warnings as blockers.
  • Your disallowed calls are framework-specific (e.g., WordPress hooks) and better handled by custom PHPStan rules.

How to Pitch It (Stakeholders)

For Executives/Business Leaders

"This tool is like a ‘static code firewall’ for PHP. It automatically catches risky or deprecated function calls (e.g., security holes, performance anti-patterns) before they reach production—saving us from vulnerabilities and tech debt. For example, it can block eval() or dynamic SQL queries in new code, while letting our legacy payment system (which uses mysql_connect) keep running during migration. It’s low-cost (MIT license), integrates with our existing CI, and reduces the burden on QA by catching issues early. Think of it as insurance for our codebase."

Ask: "Would you prioritize reducing security incidents and maintenance costs over a small upfront setup effort?"

For Engineering Teams

*"This extends PHPStan to enforce a whitelist of allowed calls, which is critical for:

• Security: Blocking eval(), shell_exec(), or unsafe preg_replace callbacks.
• Consistency: Preventing str_replace in string-heavy codebases where Str::of() is preferred.
• Legacy Cleanup: Flagging mysql_* calls in new PRs while grandfathering existing systems.

How it works:

1. Define disallowed items in phpstan.neon (e.g., disallowedFunctions: ['eval', 'create_function']).
2. Use @phpstan-disallowed annotations to temporarily allow calls in specific places (e.g., legacy payment code).
3. Integrate with CI to block PRs with violations (configurable severity).

Trade-offs:

• Pros: Zero runtime overhead, catches issues pre-commit, flexible allowlists.
• Cons: Requires PHPStan setup; devs must learn to use annotations for exceptions.

Next steps:

• Run a one-time audit on the codebase to identify violations.
• Pilot in non-critical modules first (e.g., new features).
• Pair with education on why these rules exist (e.g., ‘Why we block str_replace’)."*

Ask: "Can we allocate 2 hours to configure this and test it on a sample module?"