Phpstan No Private Laravel Package

Product Decisions This Supports

• Enforcing Clean Architecture Principles: Aligns with Laravel’s shift toward explicit dependency injection and encapsulation by prohibiting private members in public APIs, reducing hidden dependencies and improving testability.
• Accelerating Migration to PHPStan 2.0+: Justifies adoption of stricter static analysis (Level 10+) as part of a broader tech debt reduction initiative, with this package serving as a low-risk entry point.
• Reducing Accidental Coupling: Prevents "leaky abstractions" (e.g., private methods called from services) by treating such violations as deprecation warnings, forcing refactoring toward modular design.
• Roadmap for Laravel 10+: Supports Laravel’s evolving best practices (e.g., Laravel 10’s focus on strict typing) by integrating with modern PHPStan features.
• Build vs. Buy: Eliminates the need to maintain custom PHPStan rules, saving engineering time while enforcing consistency across the codebase.
• Developer Experience (DX): Reduces cognitive load by automating enforcement of architectural patterns, allowing developers to focus on features rather than manual code audits.

When to Consider This Package

Adopt if:

• Your team is committed to PHPStan (or planning to adopt it) and wants to enforce strict encapsulation (e.g., no private properties in public classes).
• You’re refactoring legacy Laravel code toward cleaner architecture (e.g., Hexagonal, DDD) and need to identify "leaky" private members.
• Your CI/CD pipeline already includes static analysis, and you’re willing to treat violations as blocking issues (not just warnings).
• You’re using Laravel 8.0+ with dependency injection and want to align with Laravel’s recommended patterns (e.g., protected or public properties over private).
• You need a lightweight, opinionated solution to reduce technical debt without heavy customization.

Look elsewhere if:

• Your codebase heavily relies on private properties (e.g., legacy Eloquent models with private attributes), requiring significant refactoring.
• Your team lacks PHPStan maturity—developers may resist strict rules or struggle with false positives.
• You’re not using PHPStan (this package is a thin wrapper; consider native PHPStan rules or other tools like Psalm).
• You need granular control over which private members to allow (e.g., exceptions for specific classes/methods), as the package enforces a binary rule.
• Your project is monolithic with no clear module boundaries, making encapsulation less critical.

How to Pitch It (Stakeholders)

For Executives: "This package helps us automate architectural best practices in our Laravel codebase. By integrating with PHPStan, we’ll catch and fix ‘leaky’ private methods/properties early—before they cause bugs or make the code harder to maintain. It’s a low-code, high-impact way to improve code quality, reduce technical debt, and align with modern Laravel practices. The setup is minimal, and the payoff is cleaner, more modular code that’s easier to test and extend. Think of it as a static analysis ‘lint’ for architecture."

For Engineering (Developers/Tech Leads): *"This is a PHPStan extension that enforces no private members in public APIs, which helps us:

• Avoid accidental coupling (e.g., private methods called from services).
• Align with Laravel’s patterns (e.g., explicit dependencies over hidden state).
• Catch issues early in CI/CD before they spread. It’s zero-config for basic use—just install it and run PHPStan. If you’re already using PHPStan, this is a 5-minute upgrade for a big quality boost. We’ll need to refactor some legacy private properties, but it’s a one-time cost for long-term maintainability."*

For Architects/Tech Leads: *"This package enforces encapsulation by treating private member usage as a deprecation warning. Key benefits:

• Reduces hidden dependencies: Forces explicit APIs (e.g., public getters/setters or constructor injection).
• Supports modular design: Prevents cross-module coupling via private methods/properties.
• Works with Laravel’s service container: Encourages protected or public properties over private ones, improving testability. We’ll need to phase in refactoring (e.g., start with new code or critical modules), but the long-term ROI is cleaner, more maintainable architecture."*