Soft Deleteable Extension Bundle Laravel Package

Technical Evaluation

Architecture fit — poor for a Laravel codebase. The artifact is named and packaged as a bundle (...-extension-bundle), which is Symfony's distribution unit. By convention that means it registers through Symfony\Component\HttpKernel\Bundle\Bundle, ships a DependencyInjection/*Extension.php config tree, and hooks into Doctrine ORM's event system (onFlush, loadClassMetadata, postFlush) to intercept deletes and rewrite them as deletedAt updates. Laravel has no bundle/compiler-pass model — there is no kernel to register it with and no services.yaml to autowire it into. So this is not a Laravel package that happens to be Symfony-flavored; it is a Symfony package that a Laravel team would have to consume indirectly or reimplement.

Functional overlap is total, which is the real finding. Laravel ships Illuminate\Database\Eloquent\SoftDeletes as a first-class trait: global scope filtering, withTrashed(), onlyTrashed(), restore(), forceDelete(), and deleted_at casting/Carbon handling. Any business case for this package must therefore rest on something Eloquent does not do — plausible candidates are cascade soft-delete across relations, SQL-level filtering that survives raw query builders, or configurable per-entity behaviour via annotation/attribute. That value proposition is unverified and, at 3 stars and 0 dependents, unvalidated by anyone else.

Integration feasibility — low-to-medium, and conditional on Doctrine. Adopting it in Laravel requires Doctrine ORM (doctrine/dbal plus an entity manager) alongside Eloquent, effectively running two persistence layers with two schema authorities. That means dual migration tooling, two hydration paths, and ORM event listeners firing on a connection Eloquent doesn't own. The only coherent scenario is a team already standardized on Doctrine within Laravel (uncommon), or a Symfony service in a mixed estate where Laravel is the consumer of a shared database — and even then you'd typically depend on the underlying event-listener library directly rather than pull the bundle wrapper.

Technical risk — moderate, concentrated in maintenance rather than code quality. MIT licensing is clean and the 2025-04-02 release shows the repo isn't abandoned. But 3 stars, 0 dependents, and a single publishing foundation means zero production telemetry: no downstream projects to absorb breaking changes, no community security review, no track record of CVE response. Version constraints against PHP 8.3/8.4, Symfony 6/7, and Doctrine ORM 3 are unknown and are the most likely source of install friction.

Key questions to resolve before any engineering spend:

1. What does this do that SoftDeletes plus a deleted_at global scope does not? Get a concrete diff list.
2. Does the bundle's logic live in classes that are usable without a Symfony kernel (listener + attribute + config object), or is it welded to the container?
3. What are the composer.json constraints for PHP, Doctrine ORM, and Symfony components?
4. What is the test coverage, and does CI run against a matrix of supported versions?
5. Is there a second maintainer, and is there a documented release/BC policy?
6. Does the 2025-04 release contain functional changes, or is it a constraint bump?

Bottom line on the scoring: the 0.245 overall score with a 17.64 "opportunity" sub-score is a classic low-adoption/high-headroom signal, not a fitness signal. The opportunity metric rewards empty niches; it should not be read as evidence that this package solves a problem your stack has.

Integration Approach

Stack fit: none, unless Doctrine is already present. For a standard Eloquent-based Laravel application the recommendation is to not integrate and instead extend Laravel's native soft deletes (custom trait composing SoftDeletes, relation-aware cascading in the deleting model event, and a deleted_at index). For a Doctrine-based Laravel service or a Symfony service, the package is a candidate — but evaluate gedmo/doctrine-extensions (SoftDeleteable) first, since it is the de facto standard with vastly larger adoption and would give you the same behaviour with a maintainable upgrade path.

Compatibility to verify in the first hour. Confirm PHP constraint covers your runtime (8.2/8.3/8.4), confirm Doctrine ORM major version alignment, and confirm whether the bundle requires symfony/framework-bundle as a hard dependency. If it does, that alone disqualifies Laravel — Laravel pulls individual Symfony components (console, http-foundation, routing) but never the framework bundle or a kernel.

Migration path, if you proceed. Treat it as a spike, not a migration:

• Week 1 — feasibility spike (1–2 days): standalone script bootstrapping the listener outside Symfony, exercising create/soft-delete/restore/force-delete against a scratch schema. If it can't run without a kernel, stop.
• Week 2 — isolation: wrap whatever behaviour you actually need behind a domain-level interface (e.g. ArchivableRepository) so the package is an implementation detail, not a model-level dependency smeared across entities.
• Week 3 — dual-run validation: run the new path in parallel with native Eloquent soft deletes on a shadow table; assert identical result sets for the queries that matter (including withTrashed equivalents and aggregate counts).
• Never retrofit incrementally into a live schema. A soft-delete mechanism change rewrites the semantics of every existing query; a partial cutover produces rows that are invisible to one layer and visible to the other.

Sequencing guardrail: don't start until question 1 (the concrete diff vs. native SoftDeletes) has a written answer. If the answer is "cascade soft delete," that is roughly 40 lines of trait code and not worth a dependency with zero dependents.

Operational Impact

Maintenance burden is effectively fork ownership. With 0 dependents, your team becomes the only real consumer. Expect to vendor or patch the package for PHP/Doctrine upgrades, and budget roughly 1–3 days per year of reactive maintenance at minimum — more if it sits on a hot upgrade path (PHP majors, Doctrine ORM 3). Pin the version explicitly and mirror it internally; a 3-star repo disappearing or going quiet is a realistic scenario, and Composer will happily fail your build when it does.

Support is self-support. No StackOverflow footprint, no documented issue SLA, no community Slack. Debugging lands entirely on your engineers reading vendor source. The flip side is that MIT + small surface area means you can read all of it, which is worth something.

Scaling considerations — this is where soft deletes bite regardless of library. Deleted rows accumulate, so table size and index size grow monotonically; add a partial/functional index on deleted_at IS NULL and plan an archival job that hard-deletes beyond a retention window. Every query gains a WHERE deleted_at IS NULL predicate — verify it lands on your composite indexes and doesn't cause plan regressions on the hottest read paths. Watch unique constraints: a UNIQUE(email) will block re-registration of a soft-deleted user, and the library will not solve that for you. Bulk deletes via query builder frequently bypass ORM listeners entirely — confirm and, if so, route them through the listener deliberately or accept that they hard-delete.

Failure modes to design against:

• Silent data leakage: listener fails to register or a raw query bypasses the global scope → soft-deleted records resurface in user-facing output. Highest-severity failure; needs an integration test asserting invisibility per entity.
• Silent hard delete: the inverse, where a delete path (bulk, cascade, direct SQL) is not intercepted and rows vanish irrecoverably. Equally severe, harder to detect.
• Orphaned relations: child rows retain deleted_at = NULL while the parent is archived, producing dangling references in reports and joins.
• Compliance conflict: GDPR/erasure obligations generally require actual deletion of personal data; soft delete does not satisfy them. Any PII-bearing entity needs a genuine hard-delete or anonymization path, and this package won't provide it.

Ramp-up cost. A mid-level Laravel engineer needs roughly 1–2 weeks to become productive with Doctrine's event system and this bundle's internals — time spent learning a paradigm that has no application elsewhere in the codebase. That is a recurring tax paid on every future engineer who touches the model layer, and it is the strongest argument for staying with native SoftDeletes unless the functional gap is genuinely load-bearing.