Product Decisions This Supports
- Retention policy definition. The core product decision this package sits behind is "how long do we keep recoverable deleted data?" That is a policy choice with three constituencies — users (undo/restore window), finance (storage cost), and legal (erasure commitments). This package makes the technical enforcement of that policy a config value rather than a bespoke cron job, which shortens the loop between "we decided 30 days" and "the system does 30 days."
- Build vs. buy vs. copy. At 47 stars, zero dependents, and archived status, this is not a "buy" (it's MIT, so there is nothing to buy) — it's a reference implementation. The decision it informs is whether your team writes the purge logic from scratch or copies a 100-line trait and its tests. For most teams the honest answer is "copy the pattern, own the code."
- Compliance commitments. If sales or legal want to state "deleted records are permanently purged within N days" in a DPA, privacy policy, or security questionnaire, you need a deterministic purge mechanism. This package is a candidate answer to that question — but only as a starting point, since the archived status means you cannot rely on upstream fixes when an auditor asks.
- Soft-delete UX scope. Whether to build "Trash" / "Restore" surfaces with visible expiry ("this item will be deleted in 12 days") depends on whether hard deletion is automated and reliable. This package changes that from a roadmap item into a configuration detail.
- Use cases where it maps cleanly: GDPR/CCPA right-to-erasure SLAs, user-facing "recently deleted" recovery windows, log/notification/audit-row pruning, and internal admin tools where permanent deletion of stale rows is housekeeping rather than a feature.
When to Consider This Package
Consider referencing it if:
- You are on a Laravel version contemporary with its Feb 2022 release (Laravel 8/9) and need a retention-based purge in a prototype, internal tool, or throwaway service.
- You want a worked example of a trait-based
$hardDeleteAfterDays pattern to hand to an engineer as a spec.
- Your dataset is small and single-tenant, and a read-time or command-time sweep of soft-deleted rows is acceptable.
Look elsewhere — or write it yourself — if any of the following apply:
- You are on a current Laravel (10/11/12) or PHP 8.2+. Archived since 2022 with no releases and no dependents means no compatibility guarantee and no security response path. This is the dominant criterion.
- You are in production with real user data. Purging is destructive and irreversible; a bug is not a broken page, it is unrecoverable data loss. That risk profile demands a maintained dependency or first-party code, not an abandoned package.
- You need operational safety. Look for (or require) chunked/batched deletion, queue offloading so the purge doesn't block requests, dry-run mode, per-model retention overrides, multi-tenancy scoping, and an audit trail of what was purged and when. A 2022 single-purpose package is unlikely to offer all of this, and you cannot ask for it.
- Purge happens on read rather than on a schedule. If the mechanism force-deletes when a soft-deleted model is retrieved, that is a red flag: destructive side effects inside GET requests, unpredictable timing, and no idempotent job you can monitor or retry.
- You need to prove control to an auditor. "We depend on an archived community package" is a harder sentence to write in a SOC 2 or ISO 27001 evidence pack than "we implemented and unit-tested a scheduled command."
The pragmatic recommendation for nearly every team: treat the repo as a design reference, spend the half-day to implement a scheduled PurgeSoftDeletedRecords command with a per-model retention config, chunked deletes, and logging — and own it.
How to Pitch It (Stakeholders)
To executives: This is a small, MIT-licensed open-source utility that automates permanent deletion of records users have already deleted, after a retention window we choose. It costs nothing to license, but the project has been archived since early 2022 and has no downstream users — so I do not recommend depending on it. My recommendation is to treat it as a reference and have engineering build the equivalent in-house, which is roughly a day of work and removes the supply-chain and maintenance risk entirely. That gives us a defensible answer for privacy commitments ("purged within N days") without adding an unsupported dependency to our stack.
To engineering: The pattern is a model trait plus a scheduled command that force-deletes soft-deleted rows older than a configurable window. It is worth reading for the API shape, not for the code. We should implement it ourselves: a queued, chunked artisan command, retention configured per model, structured logging of purged IDs and counts, a dry-run flag, and a test that asserts nothing inside the retention window is touched. Do not add it to composer.json — the package is archived, unmaintained, predates Laravel 10, and a defect here means unrecoverable data loss rather than a cosmetic bug.