Eloquent Cascade Laravel Package

Product Decisions This Supports

• Data-retention and deletion semantics. This package makes "what happens to dependent records when the parent is deleted" an explicit, configurable product decision rather than an accident of schema. That directly supports decisions about soft-delete windows (reversible trash vs. permanent purge), account/workspace offboarding, and erasure requests.
• Build vs. buy for deletion logic. The real decision this informs is: (a) DB-level ON DELETE CASCADE foreign keys, (b) hand-rolled model observers/events, or (c) a small package. Since soft deletes cannot be expressed as a database constraint, any product with SoftDeletes plus parent-child data has to solve this in application code — this package is a pre-built answer to that narrow question.
• Feature scoping for cleanup workflows. Typical use cases: deleting a tenant/account cascades to projects, documents, comments, attachments; content hierarchies (post → comments → media); admin "purge" actions; scheduled retention jobs that hard-delete expired soft-deleted trees.
• Roadmap risk allocation. Adopting it is a low-cost way to ship delete behavior without migration work, but it creates a (small) unmaintained dependency. The PM decision is whether to absorb ~1–2 days of engineering to vendor/fork it versus writing observers in-house — not whether to make deletion correctness a priority.
• Auditability and compliance posture. Cascading hard deletes make GDPR/CCPA erasure cheaper to implement but also make irreversible deletion easier to trigger accidentally; this package forces the team to decide, per model, which relations cascade and whether the cascade is soft or hard — a decision that should be documented.

When to Consider This Package

Adopt (or, more likely, read and vendor) it when:

• Your models already use SoftDeletes and you need cascade behavior across hasMany/morphMany relations, where database foreign keys cannot help.
• The relation graph is shallow and mostly conventional (2–3 levels), and the team prefers a declarative trait over bespoke observers in every model.
• You are shipping an internal tool, MVP, or admin surface where speed matters more than long-term dependency hygiene.
• You want a reference implementation of the pattern to adapt (MIT license makes this low-friction).

Look elsewhere — or write it yourself — when:

• Maintenance matters. 24 stars, 0 dependents, and a last release of April 2021 mean no ecosystem validation and no evidence of support for current Laravel versions. Verify compatibility with your Laravel/PHP version with a spike before committing; assume you may own the code.
• You need transactional or referential guarantees at scale. Prefer database-level ON DELETE CASCADE plus explicit soft-delete handling in a queued job — cascading deletes executed row-by-row in PHP can be slow and can partially fail on large trees.
• Cascade rules are conditional or business-logic-heavy (e.g., cascade only when a child is in a certain state, or emit domain events/notifications per deletion). Write observers or a dedicated service — it is on the order of tens of lines and stays testable and owned.
• Compliance/audit requirements are strict. You want deletion to flow through a single, instrumented, logged code path rather than a third-party trait.
• Your team forbids unmaintained dependencies as policy — in which case, vendor the trait into the codebase with attribution and tests rather than adding it to composer.json.

How to Pitch It (Stakeholders)

To executives: This is not a strategic dependency — it's a small, MIT-licensed utility that saves roughly one to two engineering days on "what gets deleted when we delete an account" logic, a question every product with soft deletes eventually faces. It has negligible community traction and hasn't been released since 2021, so I'd recommend treating it as a code sample we adapt and own rather than a long-term vendor dependency. Either way, the outcome is faster delivery of correct, reversible delete behavior and a documented retention policy.

To engineering: It's a trait that declaratively cascades soft and hard deletes across Eloquent relations, covering the gap where SQL foreign keys can't reach soft-deleted rows. Low coupling, easy to vendor. Two caveats before we commit: confirm compatibility with our Laravel version (no release in ~4 years), and avoid using it for deep relation trees or high-volume deletes where per-row PHP cascades will be slow — there we should prefer queued jobs or database constraints. Recommendation: one-day spike, then either vendor the trait with our own tests or write equivalent observers in-house.