Soft Deletable Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for a small, well-understood capability. Soft delete is a roughly 50–150 line concern: a nullable timestamp column, a query filter, a delete listener, and a restore path. This package is only a candidate if it saves meaningful engineering time — and at zero stars, zero dependents, and no maintenance signal, it likely does not. The default is framework-native or a one-day in-house build.
• Stack fit before feature fit. Despite the "Laravel/PHP package" framing in the request, this is a Symfony bundle for Doctrine entities, not an Eloquent package. For a Laravel product the build-vs-buy question collapses immediately: Eloquent's built-in SoftDeletes trait already covers delete(), restore(), forceDelete(), withTrashed(), and onlyTrashed(). There is no capability gap to buy.
• "Recycle bin" / undo-delete UX scoping. If the product wants admins to restore records, this shapes decisions on which entities are soft-deletable, who can restore, how long deleted records are retained, and whether deletion is reversible at the product level versus final.
• Data retention and compliance posture. Soft delete is frequently proposed as a GDPR/CCPA answer. It is not erasure — rows persist in the primary store. That requires a separate hard-delete/purge or anonymization path and documented retention windows, none of which this package provides.
• Referential integrity vs. history. Keeping rows protects historical references (orders pointing at a "deleted" customer) and supports reporting on records that no longer exist operationally. This is a product-value argument for soft delete generally, not for this dependency.
• Roadmap sequencing and schema consequences. Adopting a soft-delete layer early shapes later decisions: unique constraints (a soft-deleted row still collides with a unique index), default query-filtering behavior, indexing on deleted_at, table growth, and archive/partitioning strategy. These costs exist regardless of which implementation is chosen.
• Dependency governance. A package with 0 stars and 0 dependents implies an internal fork-and-own commitment. That is a resourcing decision, not just a technical one, and it should be made explicitly by whoever owns long-term maintenance.

When to Consider This Package

Adopt only if all of the following hold:

• The stack is Symfony + Doctrine ORM. The package is a Symfony bundle with bundle auto-discovery, DI conventions, and DoctrineBundle registration — none of which exist in Laravel.
• You have read the source and are prepared to vendor or fork it, since you will in practice be the maintainer.
• The license is compatible with your distribution model (verify directly — not stated in the materials).
• The PHP and Doctrine versions in the repo match your platform; there is no evidence of active compatibility testing.
• You have already ruled out Gedmo's SoftDeleteable for a specific, documented reason.

Look elsewhere — strongly — in these cases:

• Laravel / Eloquent: use the native SoftDeletes trait. This package adds nothing and does not apply. Even in a Laravel app that uses Doctrine via laravel-doctrine/orm, the bundle will not auto-register and would require a custom service provider to wire its event subscriber — reverse-engineering an unadopted package to replicate a feature you can get in one line.
• Symfony / Doctrine, mainstream choice: gedmo/doctrine-extensions (SoftDeleteable) with stof/doctrine-extensions-bundle is the established option, with active maintenance, documentation, and a large install base.
• Any production system: the health signals are disqualifying on their own — 0 stars, 0 dependents, score 0. No third-party validation, no issue history, no release-track record, no security review. Supply-chain risk for a trivially reproducible feature is a bad trade.
• You need an audit trail: soft delete is not auditing. Use event sourcing, a history/versions table, or database triggers if the requirement is "who changed what."
• You need true deletion for compliance: a scheduled purge or anonymization job is required regardless; this package does not supply one.
• You need a first-class restore/force-delete API: the Laravel trait gives you restore(), forceDelete(), withTrashed(), and onlyTrashed() out of the box; here you write those yourself and toggle the filter manually.

Default recommendation: do not add this dependency. Implement in-house (a trait or Doctrine listener plus a query filter), or use Gedmo on Symfony/Doctrine. The in-house cost is roughly one engineering day and eliminates the dependency entirely.

How to Pitch It (Stakeholders)

For executives: We evaluated incompass/soft-deletable-bundle for recoverable deletes and retention. It is not recommended. The capability itself is valuable — users expect undo-delete, and retaining rows supports historical reporting and referential integrity — but this specific package shows no ecosystem traction (zero stars, zero known dependents, no visible maintenance), and the feature is small enough to build ourselves in about a day. On Laravel, the framework already ships this natively. Adopting unvetted third-party code to save one day creates ongoing security and maintenance exposure with no offsetting benefit, and would also commit us to owning a fork with no upstream support.

For engineering: Note the stack mismatch first — this targets Doctrine entities, so it is a Symfony bundle, not a Laravel package. On Laravel we would simply use Eloquent's native SoftDeletes trait; there is no gap to fill. On Symfony/Doctrine, the maintained option is Gedmo's SoftDeleteable via StofDoctrineExtensionsBundle, or a small custom listener plus SQL filter. Whichever route we take, plan for the known edge cases up front: unique constraints must account for soft-deleted rows; default query filtering must be explicit and consistent, because raw SQL and batch jobs bypass the ORM filter and will leak deleted records; and we need a hard-delete/purge path for retention and privacy obligations. Note also that the most dangerous failure mode of a Doctrine soft-delete subscriber is silent — if the subscriber is misconfigured, remove() becomes a permanent hard delete, so any implementation needs an integration test asserting the row survives deletion. Recommended decision: do not add this dependency; proceed with the framework-native feature or a ~1-day in-house implementation.