Laravel Expirable Laravel Package

Technical Evaluation

Architecture fit: The package fits Laravel applications that need first-class lifecycle handling for expirable Eloquent models and queries. v2.6.0 is an additive static-analysis release: it improves PHPStan support for expirable models, custom builders, relationships, date parameters, fluent methods, ID handling in expireByKey(), and schema macros. This strengthens fit for teams already using PHPStan in CI and does not alter the package’s core runtime architecture.

Integration feasibility: Low-friction. The release adds a PHPStan extension registered automatically through extension.neon, preserves model and builder types for withExpired(), onlyExpired(), onlyEternal(), and expiredSince(), and fixes type definitions across common package surfaces. No database migration or application code rewrite is indicated. Integration is primarily a Composer update plus CI/static-analysis validation.

Technical risk: Low. This appears to be a minor, non-breaking quality release focused on developer experience and static analysis. Runtime behavior risk is minimal; the main risk is static-analysis configuration interaction, such as PHPStan extension loading, baseline churn, or newly surfaced type errors in existing code. Regression tests for builders and relationships reduce risk.

Key questions: Which Laravel, PHP, and PHPStan versions are supported? Does the automatic extension.neon registration work with the team’s PHPStan setup, including custom baselines and CI configs? Are custom Eloquent builders or relationships used in ways that need type validation? Will adopting the improved types create new PHPStan findings that require cleanup?

Integration Approach

Stack fit: Strong for Laravel/PHP teams using Eloquent and PHPStan. The release directly improves type safety around expirable model scopes, custom builders, and schema macros without changing the package’s operating model.

Migration path: Treat as a routine minor upgrade. Update the package via Composer, run the existing test suite, run PHPStan, and compare new findings against the current baseline. No data migration or schema change is expected from the release notes.

Compatibility: Likely backward compatible under SemVer. The changes are additive type improvements and test coverage. Validate compatibility with the project’s PHPStan version and confirm that extension.neon is loaded as expected in CI and local tooling.

Sequencing: Update the package in a branch; run unit/feature tests; run PHPStan and review any new type findings; update baselines only where findings are intentional; then merge and roll through normal CI/CD. If PHPStan is not yet used, adopt this release as an opportunity to introduce static analysis with a baseline-first rollout.

Operational Impact

Maintenance: Low ongoing maintenance. The package continues to invest in type correctness and regression tests, which should reduce long-term integration friction for typed Laravel codebases.

Support: Improved developer support through better PHPStan diagnostics and preserved types for scopes, builders, relationships, date parameters, and schema macros. This should reduce time spent debugging false positives or weak type inference.

Scaling: No direct runtime scaling impact. Indirect benefit is improved code quality and safer refactoring as usage of expirable models and custom query scopes grows across a larger Laravel codebase.

Failure modes: Primary failure modes are static-analysis related: PHPStan extension not loaded, version mismatch, new findings against an existing baseline, or inaccurate custom builder/relationship typings. Runtime failure risk is low based on the release scope.

Ramp-up: Minimal for teams already using PHPStan. Teams new to PHPStan should expect some initial setup and baseline work, but the package’s automatic extension registration and regression tests reduce the learning curve.