Laravel Presenter Laravel Package

Product Decisions This Supports

• Build vs. buy for view-layer formatting: this package is a thin, opinionated implementation of the presenter/decorator pattern — a base class plus a make:presenter generator that wraps a model and exposes display-ready accessors. Adoption is a low-cost way to standardize where formatting logic lives (formatted dates, money, status labels/badge classes, name concatenation) instead of scattering it across Blade templates, API resources, and accessors. The realistic "build" alternative is 100–200 lines of in-house base class plus a generator — decide buy only if the team values the convention over owning the code.
• Architecture/roadmap fit is now the gating question, not features: v2.2.0 is a pure compatibility release (Laravel 12/13, PHP 8.2–8.4). It confirms the package is tracking the framework's release cadence, which is the main risk with thin view-layer utilities. It does not add capability — so it should not, on its own, trigger a roadmap change or a migration.
• Use cases worth scoping against: admin/back-office UIs and Blade-heavy surfaces where the same model is rendered many ways; multi-channel output where the same entity needs HTML labels for the web and plain strings for exports/notifications; teams onboarding juniors who benefit from a named place to put presentation logic. Poor fit for API-only products already standardized on Eloquent API Resources — a presenter there adds a second, competing serialization layer.
• Upgrade decision: for a product on Laravel 10/11, this release is a no-op and can be taken on the normal dependency-refresh cadence. For a product planning a Laravel 12/13 upgrade, this release removes the package as a blocker — worth noting in the upgrade plan's dependency checklist. The pestphp/pest-plugin-laravel removal is a dev-dependency cleanup and carries no production risk.
• Portfolio consistency: if multiple internal apps use presenters, pinning them all to ^2.2 keeps a single shared convention and avoids divergent in-house forks.

When to Consider This Package

Adopt when all of the following hold:

• The product has a meaningful Blade/HTML presentation surface (not API-only).
• Formatting logic is currently duplicated or living in models/views and is causing real churn or review friction.
• The team is on, or actively planning, Laravel 10–13 / PHP 8.1–8.4 — the CI matrix in this release covers that range, so the support claim is test-backed rather than aspirational.
• You want the convention and generator more than the implementation; the package is small enough to vendor/fork if needed.

Look elsewhere or skip when:

• You are API-first and already use API Resources / DTOs — adding presenters duplicates the transformation layer.
• You need a heavyweight theming or view-model system (e.g., full ViewModel/component frameworks) — this is deliberately minimal.
• Single-maintainer OSS risk is unacceptable for a critical path. Given the package's small surface, the mitigation is straightforward: pin the version, and be prepared to fork — the base class is not deeply coupled to Laravel internals.
• You are on Laravel ≤9 or PHP ≤8.0; this release's matrix starts at Laravel 10 / PHP 8.1, so older stacks are effectively out of support.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk developer-productivity dependency, not a platform bet. The new release is maintenance-only — it adds support for Laravel 12/13 and PHP 8.2–8.4 and fixes a console-command incompatibility under Laravel 13. The business value is consistency: one agreed place for display formatting, which reduces scattered template logic and speeds up UI changes. No user-facing behavior changes, no migration work, no cost.

To engineering: v2.2.0 is a compatibility and hygiene release: framework/runtime matrix widened to Laravel 10–13 and PHP 8.1–8.4, a PresenterMakeCommand::configure() return-type fix for Symfony/Console under Laravel 13, and removal of a dev-only Pest plugin that was blocking Laravel 13. No API changes, no deprecations, semver-minor — safe to bump. Take it now if you're planning a Laravel 12/13 upgrade, since it clears a blocker; otherwise fold it into routine dependency refresh. Note the package is intentionally thin (a presenter base class + make:presenter generator), so treat it as a convention we adopt, with a realistic fallback of vendoring the base class if upstream maintenance lags a future major Laravel release.