Plugin Laravel Laravel Package

Technical Evaluation

Architecture Fit

• Laravel-Specific Static Analysis: Remains deeply integrated with Laravel’s architecture, particularly Eloquent ORM and query builder methods. The fix for whereDate() with DateTimeInterface values (e.g., Carbon) demonstrates continued alignment with Laravel’s evolving API.
• Taint-Based Security: Unchanged—still leverages Psalm 7’s data-flow analysis for SQLi, XSS, and SSRF detection. The plugin’s core value (security-focused static analysis) remains intact.
• Complementary to Larastan: No overlap with type safety tools; this plugin’s focus on security (e.g., taint propagation) remains unique in Laravel’s tooling ecosystem.

Integration Feasibility

• Minimal Setup: Unchanged—still requires composer require and psalm-laravel init. The fix for whereDate() reduces manual stubbing for common Carbon/Laravel patterns.
• Psalm 7.x Dependency: No change—still requires Psalm 7 (beta). The plugin’s reliance on Psalm 7 remains the primary integration hurdle.
• Facade & Stub Generation: Automated stub inference for facades/collections is unchanged, but the whereDate() fix reduces false positives for Carbon-based queries.

Technical Risk

• Psalm 7 Beta Stability: Unchanged risk—beta status may introduce breaking changes. Monitor Psalm’s release notes.
• False Positives/Negatives:
  • Reduced Risk: The whereDate() fix mitigates a specific false positive for DateTimeInterface in Eloquent queries, improving accuracy for Carbon/Laravel users.
  • New Edge Cases: The plugin may still misclassify complex taint flows (e.g., middleware chains). Requires tuning via psalm.xml.
• Migration Overhead: Unchanged—upgrades to Laravel 12/13 and PHP 8.2+ are still prerequisites. The whereDate() fix lowers the barrier for Carbon-heavy projects.

Key Questions

1. Compatibility:
   • Does the project use Carbon/Laravel’s whereDate() with DateTimeInterface values? If so, this fix resolves a prior false positive.
   • Are there other Eloquent query methods (e.g., whereTime, whereMonth) that may still trigger false positives?
2. Security vs. Performance:
   • How will the plugin’s overhead impact CI/CD? Taint analysis remains computationally intensive.
   • Can the whereDate() fix reduce CI runtime by eliminating suppressed errors?
3. Adoption Strategy:
   • Should the team re-run baseline generation to capture the fix’s impact?
   • Can the plugin now be enabled for more strict taint analysis (e.g., --level 3) without overwhelming developers?

Integration Approach

Stack Fit

• Laravel Monoliths/Microservices: Ideal for projects using Eloquent/Query Builder with Carbon. The whereDate() fix specifically benefits:
  • Carbon-heavy applications (e.g., event scheduling, date-range queries).
  • Legacy Laravel projects migrating to stricter static analysis.
• Hybrid Tooling: Unchanged—complements Larastan (type safety) and PHPStan (general analysis). No overlap with runtime scanners (e.g., Snyk).
• CI/CD: Unchanged—designed for GitHub Actions but adaptable to other CI systems.

Migration Path

1. Pre-requisites: Unchanged—upgrade Laravel/PHP to supported versions.
2. Plugin Installation: Unchanged—composer require psalm/plugin-laravel:^4.8.
3. Baseline Update:

   ./vendor/bin/psalm --set-baseline=psalm-baseline.xml --ignore-baseline
   

   Critical: Re-generate the baseline to incorporate the whereDate() fix and avoid suppressing resolved issues.
4. CI Integration: Unchanged—use psalm-laravel add github or manual workflows.

Compatibility

• Psalm Configuration: Extend psalm.xml to include the fix’s scope:

  <plugins>
      <pluginClass class="Psalm\LaravelPlugin\Plugin" />
  </plugins>
  <taintAnalysis>
      <source>Psalm\LaravelPlugin\TaintSources\RequestInput</source>
      <sink>Psalm\LaravelPlugin\TaintSinks\SqlQueryBuilder</sink>
  </taintAnalysis>
  

  Note: The whereDate() fix reduces the need for @psalm-suppress annotations for Carbon-based queries.
• Database Schema: Unchanged—still parses migrations for Eloquent model types.
• Facade Aliases: Unchanged—dynamically resolves Laravel’s AliasLoader.

Sequencing

1. Initial Run: After upgrading, run with --level 4 to balance strictness and noise.
2. Iterative Tuning:
   • Prioritize: Fix TaintedSql errors (security-critical) over type issues.
   • Leverage Fix: The whereDate() resolution may reduce false positives in date-related queries.
3. CI Gating: Start with non-blocking runs (--output-format=github), then enable failure gates for critical paths.

Operational Impact

Maintenance

• Plugin Updates: Monitor for v3.15 (next major release). The whereDate() fix suggests improved Eloquent support but may introduce new risks.
• Configuration Drift: Update psalm.xml if new Laravel features (e.g., Eloquent 10+) require taint analysis adjustments.
• Baseline Management:
  • Action Required: Re-generate the baseline post-upgrade to avoid carrying forward suppressed whereDate() errors.
  • Schedule annual baseline reviews to prevent bloat.

Support

• Debugging Issues:
  • Use --no-cache for troubleshooting.
  • Check psalm.log for traces; refer to the issue catalog.
  • For whereDate()-related errors, verify Carbon/Laravel versions are compatible.
• Community Resources: Unchanged—GitHub Discussions and sponsor support remain available.

Scaling

• Performance:
  • Taint Analysis: Still scales poorly for large codebases (>50K LOC). Mitigate with:
    • Path filters in psalm.xml (exclude tests/).
    • Parallel execution (--threads=4).
  • Memory: Cache cleanup remains necessary (rm -rf ~/.cache/psalm).
• CI Bottlenecks: Unchanged—use GitHub Actions caching and igbinary for speed.

Failure Modes

Ramp-Up

• Onboarding Steps:
  1. Developer Training:
     • Highlight the whereDate() fix as a resolved false positive for Carbon queries.
     • Document how to re-generate the baseline post-upgrade.
  2. CI Rollout:
     • Start with non-blocking runs to observe false-positive volume.
     • Enable failure gates for security-critical paths (e.g., API controllers).
  3. Carbon-Specific Guidance:
     • Example: Post::query()->whereDate('created_at', Carbon::now()) no longer triggers ImplicitToStringCast.