Laravel Cascade Delete Laravel Package

Product Decisions This Supports

• Build vs. buy on deletion logic: Laravel's native ON DELETE CASCADE at the database level does not fire when a model uses SoftDeletes, and Eloquent has no built-in recursive cascade. This package closes that gap, so the decision is whether to hand-roll cascade/soft-delete traversal in every model or adopt a maintained implementation. Rolling your own is deceptively expensive once polymorphic relations and deep object graphs enter the picture.
• Data-retention and compliance roadmaps: Account deletion, GDPR/CCPA erasure requests, tenant offboarding, and "delete my workspace" flows all depend on complete, predictable cascades. A package that correctly honors soft deletes lets you offer reversible deletion (trash/restore) as a product feature rather than an engineering liability.
• Schema and data-model decisions: Adopting this shifts cascade responsibility from fragile DB constraints into application-layer model events, which is the right trade-off when you need soft deletes, audit trails, or event-driven side effects (notifications, search-index cleanup, file storage purges) to run as part of the cascade.
• Prioritization of cleanup work: Gives a concrete answer to "how much of our deletion code is bespoke and untested?" — a candidate for consolidation rather than a recurring maintenance line item in each sprint.
• Upgrade risk in this release: v1.3.4 is a patch that replaces direct manipulation of soft-delete internals with the public soft-delete API (delete(), forceDelete(), trashed() and friends). No new features, no deprecations, no breaking changes. It improves correctness and forward-compatibility with custom SoftDeletes implementations and future Laravel versions — a low-risk, recommended bump to ^1.3.4, not a roadmap item.

When to Consider This Package

Consider adoption when:

• Your domain has multi-level parent/child relationships (organizations → projects → tasks → comments → attachments) and "delete the top, clean up the bottom" is a recurring requirement.
• You use SoftDeletes on some or all of those models and need cascades that respect trashed state, restore paths, and forced deletes — the exact area this patch touched.
• You want cascaded deletions to fire model events so observers, policies, and audit logging stay consistent.
• Your team is small and you would rather not own a recursive deletion utility plus its edge cases (cycles, self-referencing tables, polymorphic morph maps).
• You are comfortable with an application-layer deletion strategy rather than database-level foreign keys.

Look elsewhere when:

• Your schema is simple and database-level ON DELETE CASCADE with hard deletes is sufficient — adding a package here is unnecessary surface area.
• You are deleting very large volumes where per-model event overhead and N+1 traversal matter; a queued/batched job or DB-level strategy will scale better.
• You need transactional guarantees across huge graphs or cross-database deletes; treat this as one component, not the whole answer.
• The package's maintenance cadence, Laravel version support, or test coverage does not meet your bar — verify the repository before committing; a single patch release is evidence of activity, not of a support policy.
• You have a strict minimal-dependency policy for a handful of models where a few lines of deleting observer code would do.

How to Pitch It (Stakeholders)

For executives: Deleting data sounds trivial and is not. When a customer closes an account or exercises a data-erasure right, every related record has to go — and if any are missed, that is a compliance and trust problem. Today that logic is written by hand, model by model, and is easy to get subtly wrong. This package is a small, focused, actively maintained dependency that handles cascading deletion correctly, including for records we only soft-delete so they can be restored. The current release (v1.3.4) is a bug fix with no breaking changes: it aligns the package with the supported soft-delete interface, which lowers our upgrade risk. Cost is near zero; the benefit is fewer defects in a high-consequence code path.

For engineering: Adopt gigerIT/laravel-cascade-delete at ^1.3.4 to replace bespoke recursive-delete logic. It runs cascades through Eloquent model events, so observers, policies, and audit hooks continue to fire, and it correctly distinguishes soft delete from force delete. The v1.3.4 fix moves the package off internal soft-delete implementation details onto the public API, which means our custom SoftDeletes traits and future Laravel upgrades are less likely to conflict. Migration is incremental — enable it per model, add tests around restore and force-delete paths, and benchmark on our largest object graphs before rolling it out to tenant deletion. Recommendation: pilot on one low-risk subtree, then standardize.