Hidev Phpstan Laravel Package

Technical Evaluation

Architecture Fit

• Plugin-Based Nature: The package is a HiDev plugin for PHPStan, meaning it extends existing PHPStan functionality within the HiDev automation framework. This aligns well with Laravel’s static analysis needs, particularly if the team already uses PHPStan or HiDev for code generation/automation.
• Laravel Compatibility: Since PHPStan is widely used in Laravel projects (via phpstan/extension-installer or manual setup), this plugin could integrate seamlessly if HiDev is already part of the workflow. However, Laravel does not natively use HiDev, so adoption would require intentional integration.
• Static Analysis Focus: The package provides PHPStan operations (e.g., running checks), which is valuable for Laravel’s type safety and maintainability goals. It could complement tools like Laravel Pint, Pint, or Psalm in a PHP-heavy stack.

Integration Feasibility

• Low Coupling: The plugin is lightweight (no major dependencies beyond PHPStan/HiDev) and does not modify Laravel core files. Integration would likely involve:
  • Adding the package via Composer.
  • Configuring HiDev to recognize PHPStan rules.
  • Potentially extending Laravel’s phpstan.neon config to include HiDev-specific rules.
• CI/CD Fit: If the team uses GitHub Actions, GitLab CI, or CircleCI, this could be added as a pre-commit or pre-deploy static analysis step, similar to how PHPStan is often used.
• IDE Support: If HiDev is used for code generation, this plugin could enhance PHPStorm/Rider integration for Laravel projects by providing real-time PHPStan feedback during development.

Technical Risk

• HiDev Dependency: The package requires HiDev (hiqdev/hidev), which is not a standard Laravel tool. Introducing HiDev adds complexity and may require:
  • Learning HiDev’s workflow (e.g., code generation, automation scripts).
  • Maintaining HiDev-specific configurations alongside Laravel’s existing tooling.
• Stale Maintenance: The package has no activity since 2020 and no dependents, raising concerns about:
  • Backward compatibility with newer PHPStan versions.
  • Bug fixes or security updates.
• Configuration Overhead: The plugin may require custom phpstan.neon or HiDev config files, adding friction if the team prefers minimal static analysis setups.
• Laravel-Specific Gaps: The package does not mention Laravel-specific optimizations (e.g., Eloquent, Blade, or framework-specific types). Users may need to manually extend PHPStan rules.

Key Questions

1. Why HiDev? Does the team already use HiDev for code generation/automation? If not, is there a clear use case for adopting it just for PHPStan?
2. PHPStan Version Support: Will this plugin work with the latest PHPStan (v1.x)? If not, what’s the migration path?
3. Rule Customization: Can this plugin extend Laravel-specific PHPStan rules (e.g., for Eloquent, Facades, or Blade)? If not, how will gaps be addressed?
4. Performance Impact: Does HiDev add significant overhead to PHPStan’s execution time? Benchmarking may be needed.
5. Alternatives: Are there Laravel-native static analysis tools (e.g., vimeo/psalm, phpstan/extension-installer) that better fit the team’s needs?
6. Long-Term Viability: Given the lack of maintenance, is the team willing to fork or maintain this package if issues arise?

Integration Approach

Stack Fit

• PHPStan Integration: The package is a drop-in PHPStan extension, so it fits into Laravel’s static analysis stack if PHPStan is already used. It could replace or supplement:
  • phpstan/phpstan (core static analyzer).
  • phpstan/extension-installer (for Laravel-specific rules).
• HiDev Integration: If HiDev is used for code generation (e.g., scaffolding, template rendering), this plugin could:
  • Validate generated code in real-time.
  • Enforce consistency across auto-generated Laravel components (e.g., migrations, models).
• Toolchain Placement:

  Tool	Role	Integration Point
  PHPStan	Static analysis	Replace/extend existing config
  HiDev	Code generation/automation	Pre-commit or CI step
  Laravel Pint/Pint	Code formatting	Post-static-analysis step
  Git Hooks/CI	Enforcement	Fail builds on PHPStan errors

Migration Path

1. Assess Current Setup:
   • Audit existing PHPStan and code generation tools (e.g., Laravel Forge, Jetstream, custom scripts).
   • Determine if HiDev’s automation features are missing from the current workflow.
2. Pilot Integration:
   • Install hiqdev/hidev and hiqdev/hidev-phpstan in a non-production Laravel project.
   • Configure HiDev to generate a sample Laravel component (e.g., a migration) and test PHPStan validation.
3. Gradual Rollout:
   • Start with optional static analysis in CI (e.g., GitHub Actions).
   • Gradually enforce HiDev + PHPStan in local development (via IDE plugins or pre-commit hooks).
4. Configuration Alignment:
   • Merge phpstan.neon with HiDev-specific rules.
   • Extend PHPStan’s services.neon to include HiDev-generated classes.

Compatibility

• PHPStan Compatibility:
  • Test with PHPStan v1.x (latest stable) to ensure no breaking changes.
  • If conflicts arise, consider forking the package or using a wrapper script to adapt configurations.
• Laravel Version Support:
  • The package does not mention Laravel-specific versions, so manual testing is required for:
    • Eloquent models, migrations, and Facades.
    • Custom Laravel extensions (e.g., Spatie, BeyondCode).
• IDE/Editor Support:
  • Ensure PHPStorm/Rider can recognize HiDev-generated files and apply PHPStan rules.
  • May require custom .idea or phpstan.neon configurations.

Sequencing

1. Phase 1: Static Analysis Only
   • Replace existing PHPStan with HiDev-augmented PHPStan in CI.
   • Validate that no false positives/negatives are introduced.
2. Phase 2: Code Generation Integration
   • Use HiDev to generate reusable Laravel components (e.g., API resources, policies).
   • Enforce PHPStan checks post-generation.
3. Phase 3: Full Automation
   • Integrate HiDev into Laravel’s scaffolding (e.g., make:model, make:migration).
   • Add pre-commit hooks to run HiDev + PHPStan locally.

Operational Impact

Maintenance

• Dependency Management:
  • HiDev and PHPStan will require regular updates, increasing maintenance burden.
  • Monitor for breaking changes in HiDev (e.g., config file locations, CLI commands).
• Configuration Drift:
  • Custom phpstan.neon or HiDev configs may diverge from upstream changes, requiring manual syncs.
• Forking Strategy:
  • Given the stale maintenance, the team may need to fork and maintain the package long-term, adding developer overhead.

Support

• Learning Curve:
  • HiDev’s automation features (e.g., templates, code generation) may require training for the team.
  • PHPStan rule customization for HiDev-generated code could need dedicated documentation.
• Debugging Complexity:
  • Issues may span HiDev, PHPStan, and Laravel, making troubleshooting harder than with native tools.
  • Example: A PHPStan error in a HiDev-generated migration could require understanding both tools’ configs.
• Community Support:
  • Limited GitHub stars/dependents suggest low community support; issues may go unresolved.

Scaling

• Performance:
  • HiDev’s code generation could add CPU/memory overhead, especially in large Laravel projects.
  • PHPStan execution time may increase if HiDev processes many files.
• Team Adoption:
  • Developer buy-in is critical; resistance may arise if HiDev feels overly complex for simple static analysis.
  • Onboarding new hires will require documenting HiDev + PHPStan workflows.
• Project Scalability:
  • Works well for monolithic Laravel apps but may be overkill for small projects or microservices.
  • Multi-repo setups could complicate HiDev configurations (e.g., shared templates).

Failure Modes