Skrepr Soft Deletable Extension Bundle Laravel Package

Technical Evaluation

Architecture fit. The package name — skrepr-soft-deletable-extension-bundle — carries Symfony bundle conventions (ExtensionBundle), which is a red flag against the stated Laravel/PHP target: Laravel has no "bundle" concept. More importantly, soft deletes are a first-class, framework-native capability in Laravel via the SoftDeletes trait plus global scopes, restore(), and forceDelete(). That means the default value proposition is redundant. This package only earns a place in the stack if it adds semantics Laravel does not ship: cascading restore/delete across relations, unique-constraint-aware soft deletion (e.g., re-usable nullable unique keys), audit history, or an admin-facing restore surface. We cannot confirm any of that from the release note, which says only "Initial release."

Integration feasibility. Composer install is presumed trivial, but the integration surface is undocumented in this release: no stated PHP version constraint, framework/Laravel version matrix, database driver support, published config, migration stubs, or naming conventions for the deleted-at column. Whether it can be adopted without a custom adapter — particularly if it is Doctrine/Symfony-oriented rather than Eloquent-oriented — is the single biggest unknown and must be resolved before any estimate is credible.

Technical risk. High, driven by maturity rather than complexity. A 1.0.0 with an empty changelog means no demonstrated stability, no deprecation policy in force, no evidence of CI, test coverage, static analysis, or a security disclosure process. Additional risks: schema convention conflicts with existing deleted_at columns, silent query-scope behavior changing reporting numbers, and supply-chain exposure to a small/unknown vendor. Soft-delete tooling is also deceptively high-blast-radius: it sits on the read path of nearly every query, so a defect manifests as data appearing or disappearing in production rather than as a clean exception.

Key questions.

1. Is this Eloquent-targeted or Doctrine-targeted, and which Laravel/PHP versions are supported?
2. What does it do that Laravel's native SoftDeletes does not? Please enumerate concrete features.
3. License, maintainer headcount, funding model, and security disclosure contact?
4. Test coverage, CI matrix, and static-analysis level — can we see the pipeline?
5. How are unique constraints, cascading deletes/restores, and relations handled?
6. Are there published config/migration stubs and upgrade guarantees (semver policy)?
7. Who else uses it in production, and at what scale?

Integration Approach

Stack fit. Assumed PHP 8.x + Composer, standard for Laravel. Fit is conditional on Eloquent support and on the additional semantics question above. If the package is Doctrine-bound, treat it as out-of-scope for the Laravel estate and stop the evaluation there rather than funding an adapter.

Migration path. None required — this is a greenfield 1.0.0 with no prior assessment and no incumbent to migrate from. That is an advantage: we can adopt it behind a trait/interface seam and swap it out later if the vendor stalls. Where it is adopted, expect a schema change (nullable deleted_at plus supporting indexes) delivered as a standard Laravel migration, and no data backfill.

Compatibility. Pin the exact version (1.0.0, no caret range) until a stability record exists. Validate against our supported PHP versions, Laravel majors, and both MySQL and PostgreSQL — partial/filtered unique indexes behave differently across the two, and unique-key-plus-soft-delete is exactly where these packages break. Confirm behavior with whereNull('deleted_at') applied to raw query builder and DB::table calls, which bypass Eloquent global scopes.

Sequencing.

1. Vendor due diligence and answers to the key questions (owner: TPM, ~3 days).
2. Timeboxed technical spike, 1–2 engineer-days: install in a throwaway app, replicate one real model with a unique constraint and two relations, exercise delete/restore/purge.
3. Architecture review with a build-vs-adopt recommendation against a ~50-line native SoftDeletes + cascade implementation.
4. If adopted: pilot in a single bounded context behind an internal interface, one release cycle.
5. Only then consider wider rollout. Do not standardize org-wide on a 1.0.0 with an empty changelog.

Operational Impact

Maintenance. The dominant cost is not code but ownership of an external dependency at version 1.0.0. Assume a single-maintainer or small-team project until proven otherwise; budget for pinning, periodic release review, and a fork contingency (retain the ability to vendor the code into our monorepo — verify the license permits it).

Support. Expect community-only support with no SLA. We must designate an internal owner for the package, otherwise soft-delete behavior becomes ambient infrastructure that nobody is accountable for when a report returns the wrong row count.

Scaling. Soft deletes scale poorly at the data layer: tables grow monotonically, index bloat accumulates, and WHERE deleted_at IS NULL prefixes every hot query. Plan for an archival/purge job and a retention policy from day one, and monitor query plans on the largest affected tables. Global scopes are convenient but can materially change execution plans without any code change on our side.

Failure modes. Most likely and most damaging: rows leaking into or vanishing from user-facing lists because a raw query bypassed the scope; unique index collisions on re-creation of a soft-deleted record; failed cascade restore leaving orphaned children; accidental hard delete through forceDelete() reachable from application code; and conflict with GDPR/right-to-erasure obligations, where "deleted" data remains readable in the table. Each needs an explicit test in the pilot.

Ramp-up. Low for engineers already fluent in Laravel's SoftDeletes — perhaps half a day if docs exist, which for this release is unverified. The real ramp-up cost is in the operational rules: when to use forceDelete, how retention jobs work, and how reporting queries must be written. Capture those as written standards before rollout, not after the first incident.