Presenter Laravel Package

Product Decisions This Supports

• Presentation-layer architecture (the real decision). This package encodes a "presenter / view-model" pattern: domain and Eloquent models stay clean, and a dedicated presenter class owns how a model is shaped for output (arrays, JSON, Blade). That is the durable decision worth evaluating — the package is only one implementation of it.
• Build vs. buy vs. borrow. With 2 stars, 0 dependents, a last release in Feb 2021, and an opportunity score of 19.31, this is not a vendor commitment — it is a reference implementation. The decision it supports is "build a thin in-house presenter layer" or "use Laravel's first-party API Resources," not "adopt a dependency."
• API/response contract consistency. If the product has multiple surfaces (mobile API, admin panel, partner exports) that render the same entities differently, presenters are a legitimate lever for keeping field naming, nullability, and formatting rules in one place instead of scattering them across controllers and Blade templates.
• Roadmap sequencing. Adopting this would create a framework-upgrade tax: an unmaintained 2021 package is a blocker on any future Laravel/PHP major-version upgrade. That belongs in the upgrade-risk line of the roadmap, not the feature line.
• Use cases where the pattern earns its keep. Multi-format output from one entity (JSON vs. CSV vs. email), locale/currency/date formatting rules that must be consistent, and read models that differ from write models. Use cases where it does not: a small CRUD app with one JSON shape per model — Laravel API Resources already covers this with zero new dependencies.

When to Consider This Package

Consider it only under narrow conditions:

• You are already running it. An existing codebase on this package is the single strongest reason to keep it — a rewrite has migration cost and zero user-visible benefit. Pin the version, add your own tests around each presenter, and budget for replacement.
• You want a 200-line reference for the pattern. Reading it to copy the idea into your own app/Presenters namespace is a reasonable use of an afternoon. That is code review, not procurement.
• Hard constraints: no Composer network access, no appetite for a first-party or actively maintained dependency, and a single-format output need that genuinely outgrows Blade helpers.

Look elsewhere — and default to looking elsewhere — when any of the following hold:

• Maintenance and security posture matter. No release since 2021, no dependents, 2 stars: no realistic path to a security patch, no compatibility guarantee for current Laravel or PHP 8.x. Any team inheriting this owns it outright.
• You need documentation, community support, or hiring signal. None of these exist at this adoption level; the bus factor is effectively one and unverified.
• You need API resources. Illuminate\Http\Resources is first-party, maintained, well-documented, and free — it is the correct default for JSON shaping.
• You need nested/compound document serialization (relationships, includes, sparse fieldsets) — spatie/laravel-fractal or API Resources with whenLoaded are the mature answers.
• You need view-layer formatting only — a Blade component or a small helper is lower total cost than a dependency.

Adoption criteria, stated plainly: do not adopt greenfield. Only retain in brownfield with a named owner and a scheduled exit.

How to Pitch It (Stakeholders)

One line for executives: This is a small, unmaintained open-source helper for formatting data before it reaches the screen or API. It is not a strategic dependency and I do not recommend adopting it — it informs our design, but we should build or use the maintained alternative.

For engineering leadership:

• The valuable asset here is the pattern, not the package: separate how data is stored from how it is presented. We want that separation regardless of which library we use.
• The package itself is a liability signal: last release 2021, 2 GitHub stars, zero dependents, MIT. No upgrade path, no security response, no community. Every hour we spend integrating it is an hour we spend owning it forever.
• Recommendation: use Laravel's first-party API Resources as the default; write a ~100-line internal presenter layer if we need Blade/multi-format formatting beyond that. Budget is hours, not a sprint.
• If we already depend on it: treat it as technical debt with a ticket, not a foundation. Contain it behind an interface so replacement is a one-file change.
• What I need from you: a decision on the presentation-layer standard, and confirmation that we are not adding unmaintained dependencies to the upgrade path.