Blade Shortcuts Laravel Package

Product Decisions This Supports

• Consistent date/time presentation across the product surface. A single Blade directive (@date($date, 'dateOrDiff')) means activity feeds, audit logs, notification timestamps, comment threads, and dashboards all render dates the same way. That removes a recurring class of design-review nitpicks and ad-hoc helper duplication.
• Roadmap input for "upcoming" and "countdown" UX. The 1.11.0 fix for future dates (anything more than ~23 hours ahead now renders the formatted date instead of "tomorrow" / "in 2 days") is a correctness change PMs should care about. Any feature showing scheduled events, deadlines, renewals, trial expiry, or calendar previews was previously at risk of misleading copy. If you have such a surface, this release is a candidate for prioritization, not just routine maintenance.
• Build vs. buy: buy/keep. The functional scope is small enough to write in an afternoon, but the value is in the accumulated edge cases — relative-vs-absolute thresholds, future dates, locale and timezone behavior under Carbon 3. Reimplementing means re-owning that bug tail. Keep the dependency; spend engineering time on product surface instead.
• Upgrade timing decision. This release drops Laravel 6–9 and PHP 8.0, and now requires PHP 8.1+ / Laravel 10+. If your platform is already on Laravel 10–12, this is a low-friction patch. If not, you must sequence the platform upgrade first, or pin to 1.10.x and accept that fixes stop flowing.
• Support matrix confidence. CI now exercises Laravel 10, 11, 12, and 13 across multiple PHP versions. That is a meaningful signal for a "boring infrastructure" dependency — it reduces the chance of a surprise break during your next framework upgrade.

When to Consider This Package

Adopt (or keep) it when:

• You are on PHP 8.1+ and Laravel 10, 11, 12, or 13 — the supported matrix is explicit and CI-verified.
• You want view-layer date formatting with near-zero ceremony — the directive keeps templates readable and avoids scattering ->diffForHumans() calls through Blade files.
• Your product has many timestamp surfaces (feeds, logs, comments, notifications) where uniformity matters more than bespoke formatting per screen.
• You value low blast radius: it is a presentation helper, not a data-layer or auth concern, so a bad release is recoverable.
• You are already on or near Carbon 3 / Laravel 11+, where the future-date bug is actually observable — the fix has real value there.

Look elsewhere or defer when:

• You are still on Laravel 6–9 or PHP 8.0. This release is a hard break; either upgrade the platform or pin to 1.10.x with a documented end-of-support date. Do not let a pinned dependency silently become unpatched.
• You need timezone-aware scheduling logic, recurring-event math, or business-calendar rules. That belongs in the domain layer, not a view directive — reach for a dedicated scheduling library or first-party Carbon logic.
• You need deep localization / ICU-grade formatting beyond what Carbon provides. A directive wrapper will not close that gap.
• Your team has a hard "no new transitive dependencies in views" policy. Reasonable, but then budget for maintaining the equivalent helper internally, including the future-date and Carbon 3 edge cases.
• Date formatting is already centralized in an API resource / presenter layer and views never touch raw dates. The marginal value drops sharply.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk presentation dependency that keeps dates consistent across the product and is now verified against the current and next Laravel releases. The 1.11.0 release fixes a real user-facing bug — future-dated items (scheduled events, deadlines, renewals) could display misleading text like "tomorrow" when they were further out. Adopting or upgrading improves copy accuracy at essentially no engineering cost, provided we are on a supported PHP/Laravel baseline. The trade-off is a formal end of support for Laravel 6–9 and PHP 8.0, which is already consistent with Laravel's own support policy and reduces our exposure to unpatched framework versions.

To engineering: Patch-level upgrade with a clearly bounded breaking change. Requirements are PHP 8.1+ and Laravel 10+; anything older must pin to 1.10.x. The future-date fix corrects dateOrDiff behavior beyond a 23-hour horizon under Carbon 3 / Laravel 11+, and the expanded CI matrix (Laravel 10–13, multiple PHP versions) gives us upgrade confidence. Action items: confirm our PHP/Laravel floor, identify any Blade surfaces rendering future timestamps and add regression coverage there, then ship. Because this is a view-layer helper, rollback is trivial — take the upgrade.