Php Deprecation Detector Laravel Package

Technical Evaluation

Architecture Fit

• Static Analysis Tool: The package is a static code analyzer, not a runtime dependency. It integrates seamlessly into Laravel’s CI/CD pipeline (e.g., GitHub Actions, GitLab CI) or local development workflows (e.g., pre-commit hooks, phpunit listeners).
• Laravel Compatibility: Works with any Laravel version (PHP 5.6+ to 8.2+) since it scans PHP code rather than interacting with Laravel’s framework-specific components.
• Non-Intrusive: No modifications to Laravel’s core or third-party packages are required—it operates as a standalone scanner.

Integration Feasibility

• CLI-Driven: Can be invoked via Artisan commands (custom or existing) or shell scripts in CI pipelines.
• Output Formats: Supports JSON/JUnit for programmatic consumption (e.g., failing builds on deprecation warnings).
• Exclusion Rules: Can skip vendor/ (third-party dependencies) and node_modules/ via --exclude, reducing noise.

Technical Risk

• False Positives: Some deprecations (e.g., strtoupper() edge cases) may trigger false alarms. Mitigation: Use --skip-checks or post-process JSON output.
• Performance: Scanning large codebases (e.g., monorepos) may slow down CI. Mitigation: Parallelize scans or limit to changed files (--max-size).
• PHP Version Mismatch: If the scanner runs on PHP 8.0 but targets PHP 7.4, some checks may be skipped. Mitigation: Use --target to align with Laravel’s PHP version.

Key Questions

1. CI/CD Integration:
   • Should failures trigger build breaks (strict mode) or warnings (gradual adoption)?
   • How to handle third-party deprecations (e.g., in vendor/)? Exclude or allow?
2. Output Handling:
   • Should JSON output be parsed by a custom script or integrated into Laravel’s logging system?
3. Version Alignment:
   • Should the scanner target Laravel’s PHP version or a future-proof version (e.g., PHP 8.2)?
4. Automation:
   • Should it run pre-commit (local) or post-merge (CI)?
   • Should it integrate with PHPStan/Psalm for combined analysis?

Integration Approach

Stack Fit

• Laravel Ecosystem:
  • Artisan: Wrap phpdd in a custom command (e.g., php artisan deprecation:scan).
  • CI/CD: Add as a pre-test step in GitHub Actions/GitLab CI.
  • Laravel Forge/Envoyer: Run on deployment to catch pre-release deprecations.
• Tooling Compatibility:
  • PHPStan/Psalm: Combine with existing static analyzers (e.g., run phpstan first, then phpdd).
  • Git Hooks: Use pre-commit to block deprecations early (requires local installation).

Migration Path

1. Pilot Phase:
   • Run in CI-only mode with --output=json to log issues without blocking builds.
   • Exclude vendor/ initially: phpdd --exclude vendor src/.
2. Gradual Adoption:
   • Add to pre-commit hooks (local) for developer feedback.
   • Integrate with Slack/Teams for deprecation alerts (via JSON parsing).
3. Strict Mode:
   • Fail builds on deprecations (adjust --target to future PHP versions).
   • Auto-generate GitHub issues/PRs for critical deprecations (via script).

Compatibility

• Laravel Versions: Works with all PHP-supported Laravel versions (5.6+ to 10.x).
• PHP Versions: Supports 5.3–8.2 (align with Laravel’s PHP policy).
• Dependencies: Only requires Symfony/Console (included via Composer) and PHP CLI.

Sequencing

Operational Impact

Maintenance

• Low Overhead:
  • No runtime dependencies; updates via Composer (composer global require).
  • Rules are version-agnostic (auto-updated with PHP releases).
• False Positive Management:
  • Maintain a whitelist (--skip-checks) for known edge cases (e.g., strtoupper()).
  • Periodically re-run scans after PHP/Laravel updates.

Support

• Developer Onboarding:
  • Document common deprecations (e.g., preg_replace with e modifier) in the team wiki.
  • Provide a cheat sheet for replacements (e.g., mcrypt_generic_end() → mcrypt_generic_deinit()).
• CI Debugging:
  • Log JSON output to artifact storage (e.g., GitHub Actions upload) for post-mortem analysis.

Scaling

• Large Codebases:
  • Use --max-size to skip giant files (e.g., 10mb).
  • Parallelize scans via GNU Parallel or CI job matrix.
• Distributed Teams:
  • Centralize JSON reports in a shared storage (e.g., S3) for cross-team visibility.

Failure Modes

Ramp-Up

1. Week 1: Install globally, scan src/ in CI, log JSON.
2. Week 2: Review top 10 deprecations, adjust --skip-checks.
3. Week 3: Add to pre-commit hooks, fail builds on critical issues.
4. Ongoing: Monitor false positives, update --target with PHP upgrades.

Key Metric: Reduce deprecation-related runtime errors by 80% within 3 months.