Laravel Cascade Soft Deletes Laravel Package

Product Decisions This Supports

• Recycle-bin / undo semantics across aggregates. If a "project" can be restored, users expect its tasks, comments, and attachments to come back too. This package lets you make soft-delete cascade down an Eloquent relationship graph declaratively ($cascadeDeletes = ['tasks', 'documents']) instead of hand-writing observers per model — so the product promise ("deleting a workspace archives everything inside it; restoring brings it back") becomes cheap to ship.
• Feature scoping: "delete" as archive, not destruction. Deciding whether DELETE means "hidden but recoverable" vs "gone" is a retention/UX decision. Cascading soft deletes makes the recoverable path coherent, which is usually the difference between shipping a delete button this quarter and shipping one with a compliance review attached.
• Data-retention and erasure policy. Supports separating archival cascades (soft delete propagates, data retained, restorable) from hard erasure (GDPR/CCPA "right to be forgotten"). The trait also overrides forceDelete to cascade hard deletes, so the two policies can be modeled as distinct code paths rather than ad-hoc admin scripts — a decision you can defend to legal/privacy.
• Build vs. buy on a small, well-bounded concern. The alternative is 50–150 lines of model events/observers maintained in-house, multiplied by every aggregate root and every new relation added. Adopting a ~1.2k-star MIT package is a low-cost way to avoid that duplication; the score's opportunity signal (32) is muted, which reads as "useful plumbing, not a strategic bet."
• API and support-load planning. Orphaned active children are a classic source of "ghost data" bugs and support tickets ("I deleted the account but my invoices still show in search"). Cascading deletes reduces that class of ticket and simplifies API contract documentation for nested resources.
• Roadmap input for audit and provenance. The gap between "children are soft-deleted" and "we know why each child was deleted" is a real product question. This package does not record cascade provenance, so if your roadmap includes audit trails or "restore only what the parent took down," budget for a follow-on (see limits below) rather than assuming this covers it.

When to Consider This Package

Consider adoption when all of the following hold:

• You're on a supported Laravel version and already use SoftDeletes broadly; the package is additive (trait + property), no schema migration, no config file.
• Your domain has clear parent→child ownership where a parent delete should hide children (tenants, workspaces, projects, orders → line items, threads → comments).
• Deletes originate primarily through Eloquent model instances ($model->delete()), not bulk query-builder statements.
• The relation graph is shallow-to-moderate and cascade fan-out is modest (hundreds to low thousands of rows per delete), so synchronous event-time work is acceptable.
• You want restore-on-restore behavior and can live with its naivety: the restoring hook re-restores everything in $cascadeDeletes, including children that were soft-deleted independently before the parent was deleted. If "undo must not resurrect a comment a moderator removed last week," you need extra bookkeeping (e.g., a deletion batch/reason column) on top.
• You're comfortable with a single-maintainer, single-purpose dependency whose contract is narrow enough to swap for in-house code in a day.

Look elsewhere, or plan to wrap it, when:

• You rely on database-level ON DELETE CASCADE or hard deletes; the package targets soft-delete graphs and won't help there.
• Bulk operations dominate (Model::where(...)->delete(), queued mass cleanup) — model events don't fire, so cascades silently don't happen. Same for raw SQL and some upsert/truncate paths.
• Volume is large: multi-million-row cascades belong in queued jobs with chunking, not in a deleting event on a web request. Watch request latency and transaction size.
• You need guaranteed referential integrity or cross-service cascades — this is application-layer best-effort, not a constraint. A crash mid-cascade can leave partial state; design idempotent cleanup/reconciliation.
• Compliance requires per-record legal hold, retention schedules, or deletion certificates — you'll need explicit deletion-reason tracking, which this doesn't provide.
• Your team already has a first-class model-lifecycle layer (observers, domain events, event sourcing) where a third trait muddies the ownership story.

Given Dependents: 0 on the metric and the single-maintainer profile, treat it as low-blast-radius convenience code: fine to adopt, but keep the usage surface small (trait + $cascadeDeletes array) so a fork or inline replacement is trivial. The recent 2026-03-20 release suggests it's still maintained, but pin the version and add a test that asserts cascade behavior on your critical aggregates.

How to Pitch It (Stakeholders)

For executives (30 seconds): "When a customer deletes a project, workspace, or account, the things inside it should disappear from the product too — and come back if the customer changes their mind. Today that's manual code repeated for every parent entity, and it's where 'I deleted it but it's still showing up' bugs come from. There's a small, free, MIT-licensed Laravel package that handles this in a few lines per model. Cost: roughly a day of engineering plus tests, no infrastructure change, no database migration. Risk: low and reversible — it's an isolated trait we can remove or replace without touching our schema or data. What I need from you is a decision on policy, not code: which entity deletions are archival (recoverable, retained) versus destructive (permanent erasure), because that determines how we configure it and what we tell customers and auditors."

For engineering: "Trait on the aggregate root, list relations in $cascadeDeletes; it hooks deleting/restoring and also overrides forceDelete to cascade permanent deletes. No migrations, no service provider required, MIT, pinned. Two caveats we should design around: (1) query-builder/bulk deletes bypass model events, so all delete entry points must go through model instances or an explicit service; (2) restore re-restores everything in the list, so if we need 'undo only what the parent took down,' we add a deletion-batch column now rather than retrofit later. Add feature tests per aggregate covering delete, restore, and force-delete paths before rollout."

Ask: approve the policy decision (archival vs. erasure per entity) and a one-day spike with tests on the two highest-traffic aggregates; we'll report back on cascade latency and orphan counts before widening adoption.