Soft Deleteable Extension Bundle Laravel Package

Product Decisions This Supports

• Data retention and "recoverable delete" UX. The package extends SoftDeleteable behavior (Gedmo/Doctrine lineage), which is only relevant if a product decision hinges on soft-deleting records, restoring them, or exposing a trash/archive view. It supports decisions like "do we let admins undelete?", "how long do we retain soft-deleted rows before purging?", and "what does our audit trail look like?"
• Build vs. buy — and the answer here is usually "build." With 3 stars, 0 dependents, and a single maintainer, this is closer to a snippet than a dependency. The correct PM decision is not "adopt" but "reference": use it to scope a small internal utility or to sanity-check an existing soft-delete implementation. In a Laravel codebase, native SoftDeletes already covers the base case, so this package contributes nothing the framework doesn't ship.
• Framework-fit gating. Despite being framed as a Laravel/PHP package, the naming (...-extension-bundle) and the underlying SoftDeleteable extension point to Symfony + Doctrine, not Laravel/Eloquent. That is a hard architectural constraint, not a preference. It should be logged as a rejected candidate for any Laravel roadmap item and only revisited if a Symfony service enters the portfolio.
• Compliance-adjacent feature work. Soft delete is frequently raised in GDPR/CCPA "right to erasure" conversations. A PM should treat this package as insufficient evidence for a compliance story — soft delete is pseudonymization/retention, not erasure. Decisions about deletion SLAs, purge jobs, and DPA language should not be sourced from a 3-star bundle.
• Multi-tenant / cascade behavior. Extension bundles like this typically exist to solve edge cases (custom filters, cascade soft-delete, restore semantics). If those edge cases are on the roadmap, that is a signal to invest in first-party logic and tests, not a third-party dependency with no downstream users to validate it.

When to Consider This Package

Consider it only if all of the following hold:

• The application is Symfony with Doctrine ORM and already depends on gedmo/doctrine-extensions SoftDeleteable — this bundle is an extension of that, so it is dead weight without it.
• You need the specific extension behavior it adds and have read the source to confirm it does what the README implies. At this size, the source is the documentation.
• The blast radius is small and reversible: one service, non-critical path, and you are comfortable vendoring or forking under MIT if the maintainer disappears.
• You have accepted single-maintainer risk explicitly and have a named internal owner for the fork.

Look elsewhere when:

• You are on Laravel. Use the built-in SoftDeletes trait and restore()/forceDelete(). No third-party package is warranted. (This is the most likely scenario given how the request was framed.)
• You need community support, security advisories, or a maintenance SLA — 3 stars and 0 dependents means no social proof and no downstream validation. Nobody else has stress-tested this in production that you can point to.
• The requirement is genuine data erasure, regulatory deletion, or cryptographic shredding.
• You need multi-tenant isolation, high write throughput, or complex cascade semantics — implement and test these in-house where you control the failure modes.
• Your team already has an abstraction over soft delete; adding a second mechanism creates two sources of truth for "is this row alive?"

Adoption verdict: reject for now, watch-list at most. The low overall score (0.245) and modest opportunity signal (17.64) are consistent with a niche, single-vendor utility rather than a platform dependency. The April 2025 release date is the only positive indicator — it is maintained, just not adopted.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a very small, MIT-licensed utility that helps a Symfony application soft-delete and restore database records. It has three GitHub stars, no downstream projects using it, and a single maintainer. It is not a strategic dependency and requires no budget or roadmap slot. If a soft-delete requirement appears, we will meet it with framework-native features (Laravel ships this out of the box) or roughly a day of internal engineering. Recommendation: do not adopt; keep on a watch list. There is no business case for taking on vendor risk here.

To engineering leads: Treat this as a reference implementation, not a dependency. Confirm the framework mismatch first — the package is a Symfony/Doctrine bundle, so it is inapplicable to our Laravel services. If we ever run a Symfony+Doctrine service with Gedmo SoftDeleteable, this might save an afternoon; even then, MIT + tiny surface area means forking is cheap and preferable to an unpinned transitive dependency with zero downstream users. Please review the source before any trial, and if we do trial it, isolate it behind our own interface so it is removable in one PR.

Bottom line for the decision log: Evaluated stichtingsd/soft-deleteable-extension-bundle. Rejected — framework mismatch with our Laravel stack, no adoption signal (3 stars, 0 dependents), single-maintainer risk. Soft-delete requirements are satisfied by framework-native capabilities. Revisit only in a Symfony/Doctrine context.