Product Decisions This Supports
- Data lifecycle & retention architecture: Deciding where deletion logic lives — database-level
ON DELETE CASCADE constraints versus application-level cascades in Eloquent. This package enables the app-layer path, which matters when you use soft deletes, polymorphic relations, or need side effects (file cleanup, audit logging, cache invalidation) on child records before/after deletion.
- Account & tenant deletion flows: A concrete building block for "delete my account," GDPR/CCPA right-to-be-forgotten requests, and multi-tenant offboarding, where a single parent delete must reliably purge an owned graph of records.
- Build vs. buy assessment: This is a tiny surface-area dependency (one trait). The real decision is whether to adopt the package, hand-roll ~50–150 lines of equivalent logic, or lean on framework-native events/observers. At 3 stars and 0 dependents, the build side of the ledger is unusually competitive.
- Referential-integrity strategy: Whether to treat orphaned rows as an app concern or a schema concern. Choosing this package signals a preference for explicit, testable, application-owned cascade rules over implicit DB behavior (which is invisible to PHP tests and hard to observe in code review).
- Engineering standards for third-party dependencies: Serving as a data point in your dependency-vetting policy — does a low-adoption, single-maintainer utility clear the bar for production use?
When to Consider This Package
Consider it when:
- You need cascading deletes that cannot be expressed as a DB foreign key — most commonly soft-deleted parents, polymorphic children, or cascade chains that must fire Eloquent events (observers, model events).
- You want cascade rules versioned in code, testable in PHPUnit, and visible during code review — useful in regulated or audited environments.
- Your schema is already fixed (e.g., a legacy DB or a managed service) and you cannot add FK constraints.
- The graph is small and shallow; you want a drop-in trait rather than a custom deletion service.
Look elsewhere (or vendor it) when:
- A plain DB-level
ON DELETE CASCADE would do the job — it is faster, atomic, and needs no dependency. This should be the default for hard-deleted, FK-constrained schemas.
- You need restore/undelete semantics that mirror the cascade — verify the trait handles restoring children; otherwise a custom soft-delete strategy is warranted.
- Adoption risk is unacceptable: 3 stars, 0 dependents, and (check) an apparently single maintainer mean no meaningful ecosystem pressure-testing, minimal community support, and a real bus-factor / abandonment risk. If you adopt, pin the version and consider copying the trait into your codebase with a license attribution rather than taking a runtime dependency.
- You need large-batch or job-queued deletion — cascading thousands of rows in-request via model events can be slow and memory-heavy; a queued purge service is likely better.
- You need compliance-grade audit trails of what was deleted — that requires purpose-built deletion logging, not a generic trait.
Due-diligence checklist before adoption: last commit date, open issues, test coverage, whether it fires model events and honors soft deletes, whether it supports forceDelete, and behavior under transactions.
How to Pitch It (Stakeholders)
For executives: This is a small, MIT-licensed utility that centralizes one of the most error-prone things we do — deleting a parent record and its children cleanly. It's low-cost and low-blast-radius. The caveat is maturity: it's an early-stage package with negligible adoption, so I would not build a compliance-critical deletion flow on it without either forking it or writing the equivalent logic ourselves. Recommendation: evaluate, don't commit. Treat it as a reference design; if we adopt, we vendor the code.
For engineering: One trait that adds cascading deletes at the Eloquent layer — the value is support for cases native FKs can't cover (soft deletes, polymorphic relations, event-driven cleanup). The cost is a runtime dependency with a single maintainer and zero downstream users. My proposed posture: spike against our two or three deletion graphs, compare against (a) DB ON DELETE CASCADE and (b) a ~100-line in-house deletion service, and pick based on whether we need soft-delete and event semantics. If the package wins, copy the trait in-tree with attribution and add tests — that eliminates the maintenance risk entirely.