Product Decisions This Supports
- Feature scoping for "recycle bin" / recovery workflows. The package exists because teams repeatedly need trash-listing, restore, and force-delete endpoints alongside standard CRUD. Its existence is evidence that soft-delete recovery is a recurring product feature, not an edge case — useful when arguing for (or against) putting recovery UX on the roadmap for admin surfaces.
- API surface standardization. If we expose restore/trash operations across many resources, endpoint naming becomes a contract question. Deciding whether
/posts/{id}/restore vs /posts/trash vs ?with_trashed=true is a product/API-design decision this package forces into the open early, before ten resources ship inconsistent conventions.
- Build vs buy for boilerplate. The realistic decision here is still not "adopt vs don't" but "do we standardize this convention internally, or let each team hand-roll trash routes?" The package is a reference implementation of the convention; the build option is a ~50-line route macro.
- Authorization and audit scope. Restore and force-delete are privileged, often destructive operations. Adding them as first-class routes forces policy work (who can purge vs restore?), audit logging, and possibly retention-policy requirements — decisions that are easy to defer and expensive to retrofit.
- Roadmap signal for platform/internal tooling. Adoption remains negligible (16 stars, zero dependents) while the underlying need is high. The 4.0.1 patch shows the project is not fully dead, but it does not change the read: the need is real, this solution isn't the one the market picked. That still points to investing in an internal convention rather than selecting a package.
When to Consider This Package
Consider it when:
- You have several (roughly 4+) Eloquent resources using
SoftDeletes and need consistent trash/restore/purge routes fast.
- The work is an internal admin or back-office surface, where the route contract is low-risk and breaking changes are contained.
- Your team values convention over configuration and would otherwise duplicate route boilerplate per controller.
- You're on a Laravel version the package supports and can pin it.
- You need a dependency-health tiebreaker: 4.0.1 is a dependency-resolution fix, which is a modest positive maintenance signal — but it is a single patch, with no dependency upgrades tracked as a policy and no feature or security roadmap behind it.
Look elsewhere — or build in-house — when:
- Maintenance matters. Treat it as a reference implementation, not a dependency. The 4.0.1 dependency fix softens the "abandoned" characterization — the repo is still receiving contributor patches, so the earlier assumption that it was archived and unreachable is no longer accurate — but one dependency patch is not a maintenance commitment. MIT licensing means you can copy the pattern outright regardless.
- You need more than routing. Policies, form requests, API resources, OpenAPI annotations, and event/audit hooks are out of scope; a route helper leaves the hard parts untouched.
- The surface is public. If these endpoints are part of a customer-facing API, endpoint naming deserves deliberate design, not a package default.
- You have one or two soft-deletable models. The dependency cost exceeds the boilerplate saved.
- You need bulk operations, scheduled purging, or retention windows. That is application logic; the package won't carry it.
How to Pitch It (Stakeholders)
For executives: This is a small, MIT-licensed convenience that codifies a common pattern — the "trash, restore, permanently delete" operations that accompany soft-deleted records. It is not a strategic dependency. A recent patch release fixed its dependency constraints, which is mildly reassuring but does not constitute a support commitment; adoption is effectively zero. Recommendation is unchanged: fund a short internal effort (roughly a day) to adopt the pattern as a shared route macro, so every team gets consistent recovery endpoints without taking on a third-party package we would have to track ourselves. The upside is user-facing (recoverable data, fewer accidental deletions) and operational (consistent conventions reduce review and onboarding cost).
For engineering: The package extends Laravel's resource routing with trash/restore/force-delete helpers, removing per-controller boilerplate. It's tiny, readable, and MIT — so evaluate it as a specification of the convention rather than a library to install. Release 4.0.1 only fixes dependency constraints; there are no API changes, no new features, and no deprecations to react to, so nothing in our evaluation changes technically. We should copy the approach into our own route macro, pair it with authorization policies and audit logging (which the package does not provide), and avoid a dependency with zero dependents and only sporadic patch activity. Net: same ergonomics, no maintenance risk, and we control the API contract.