Auto Delete Bundle Laravel Package

Technical Evaluation

Architecture fit — primary flag: the package is a Symfony bundle (NTIAutoDeleteBundle), not a Laravel package. Symfony bundles integrate through Bundle registration, DependencyInjection\Extension classes, tagged services, and (historically) annotation/attribute-driven metadata readers — none of which exist in Laravel's service-provider/container model. Laravel reuses individual Symfony components but not the bundle lifecycle. If the target application is Laravel, budget for an adapter or a re-implementation, not an install-and-go.

What it almost certainly does (verify before committing): provides declarative, attribute/annotation- or config-driven retention rules over Doctrine entities plus a console command intended to be driven by cron or a scheduler. That is a well-understood shape, which is good: even if the package itself is unusable, the pattern is cheap to replicate.

Integration feasibility:

• Symfony + Doctrine ORM + doctrine-bundle: likely low effort — composer install, enable bundle, configure entity mapping, add cron/scheduler entry. Main unknowns are Symfony 6/7 and PHP 8.2+ compatibility.
• Laravel: medium-to-high effort. Requires an Artisan command wrapper, config translation, and either Eloquent re-mapping (the bundle's internals assume Doctrine metadata/UnitOfWork) or the laravel-doctrine bridge, which adds its own risk surface.

Technical risk — high, concentrated in three places:

1. Destructive semantics. The package's core function is irreversible data deletion. A bug here is not a degraded feature; it is unrecoverable data loss and a probable regulatory incident. This dominates all other risk.
2. Zero external validation. 0 stars, 0 dependents, single-publisher, no community. Assume no meaningful public test suite, no CI matrix, no security response process, and no compatibility-tested version ranges. The opportunity score (14.38) reads as weak signal, not endorsement.
3. Silent failure / silent over-deletion. Both directions are dangerous: a misconfigured or silently failing command yields false compliance (data retained past policy), while a misconfigured field or unit mismatch yields mass premature deletion.

Key questions to answer before any code:

• What is the trigger mechanism — attribute on the entity, YAML/PHP config, or global TTL? Can rules be scoped per-entity and per-field?
• Are deletions hard or soft? Is there a dry-run/preview mode? Any audit trail emitted?
• Does it batch deletes, or issue SELECT + per-row deletes (N+1, lock escalation)? Is it chunked and transaction-safe?
• Which retention primitives are supported — fixed TTL from a timestamp column, condition-based, status-flagged, or cron-window?
• Does it respect Doctrine lifecycle events, cascades, and FK constraints, or bypass the ORM?
• What are the declared composer.json constraints (PHP, Symfony, doctrine/orm, doctrine/dbal)? Last commit date? Tests present?
• Is this an extracted internal tool from NTI Group, and is there a commercial relationship that buys an escalation path?

Verdict on fit: acceptable only for a Symfony/Doctrine estate that already has a retention requirement and a review process capable of auditing a deletion engine. For a Laravel estate, treat it as a reference implementation to port under MIT, not a dependency.

Integration Approach

Stack fit matrix:

Recommended path for a Laravel target — vendor, don't depend. MIT license permits forking the deletion algorithm into an internal Artisan command (retention:purge) with chunked delete() calls, a --dry-run default, and structured audit output. Benefits: no Symfony container shim, no version-maze, and you retain full control of the destructive path. Cost: roughly one to three engineer-days for a competent Laravel dev, versus an open-ended adapter effort.

Recommended path for a Symfony target — install with guardrails. Register the bundle, pin versions strictly, and wrap its command in your own thin command that enforces dry-run, batching limits, and audit logging before delegating.

Compatibility work up front:

• composer why-not against the current lockfile to surface constraint conflicts before design work.
• Confirm whether it uses PHP 8 attributes or legacy Doctrine annotations — the latter pulls in doctrine/annotations, which is deprecated and being removed in ORM 3.
• Check DBAL 3 vs 4 alignment; a bundle pinned to DBAL 2 is a non-starter on modern stacks.
• Verify PHPUnit/CI presence; absent tests means you write characterization tests yourself against a scratch schema.

Migration sequencing (each gate can stop the project):

1. Read the source. Full review of the deletion path, transaction boundaries, and any raw SQL. Half a day, zero infrastructure.
2. Throwaway PoC. Scratch database, seeded fixtures, dry-run only. Confirm the rule model actually matches your retention requirements.
3. Characterization tests. Pin observed behavior before change: batching, cascade handling, timezone handling, empty-set and null-timestamp cases.
4. Instrument before enabling. Audit record per deleted row (ID, table, policy, timestamp), metric counters, and a post-run assertion on row counts. Deletion without an audit trail is not deployable in a regulated context.
5. Pilot on disposable data. Session tokens, cache rows, or log tables — not customer records. Two weeks of scheduled runs with dry-run comparison against actual.
6. Legal/DPO sign-off, then per-entity rollout with a documented kill switch (config flag that disables purging without a deploy).

Abstraction recommendation: define an internal RetentionPolicy interface and keep the vendor behind it. Swapping in a first-party implementation later — or a better-maintained alternative — should be a one-class change, not a re-architecture.

Operational Impact

Maintenance — you will own the fork. With zero stars and zero dependents there is no upstream momentum to ride, and no realistic expectation of timely CVE or compatibility fixes. Plan to vendor under your own namespace with a named internal owner. Realistically this is a fork with a "re-sync quarterly and diff" policy, and you should expect to eventually diverge permanently.

Support. No community, no issue-tracker signal, no Stack Overflow corpus. Your first responder is the engineer who read the source. Estimate 2–4 hours per Symfony major upgrade for compatibility verification, plus the initial ~1–3 days of review and testing.

Scaling. Deletion is I/O-bound and deceptively expensive:

• Requires a supporting index on every retention/date column; without one, each run degrades into a table scan as the table grows.
• Must batch with bounded chunk sizes (LIMIT-driven deletes) and inter-batch pauses; single-statement mass deletes hold locks and can stall the primary.
• Schedule off-peak and cap throughput — bulk deletes generate replication lag and WAL/binlog pressure, which is a write-availability risk on the same database serving production reads.
• On large tables, expect bloat/vacuum pressure (Postgres) or fragmentation (MySQL). Consider partitioning by retention window instead of row-by-row purging once volume crosses into tens of millions.
• Verify the implementation batches. If it loads a collection then iterates deletes, memory and lock behavior are both unacceptable at scale and it must be rewritten.

Failure modes to design against:

Ramp-up. Low technical ramp-up, high governance ramp-up. Any engineer familiar with Symfony console commands and Doctrine will read the source in under a day. The expensive part is organizational: agreeing retention policies per entity, defining the audit record schema, getting DPO/legal sign-off, and rehearsing a bad-deletion incident. Budget one engineer-week end-to-end for a first production entity, most of it process rather than code.

Bottom line for planning: treat nti/auto-delete-bundle as a specification, not a supplier. Its MIT license and narrow, understandable function make it useful as a design reference; its maturity profile (0 stars, 0 dependents, unvalidated, destructive domain) makes it unsuitable as a direct dependency in a Laravel estate and only conditionally suitable in a Symfony one, behind an abstraction, an audit layer, and a kill switch.