Data Sanitize Demo Bundle Laravel Package

Technical Evaluation

Architecture fit: Effectively zero as a Laravel dependency. This is a Symfony demo bundle — a container-wiring exercise to showcase endroid/data-sanitize — and Laravel has no concept of Symfony bundles. It does not participate in the service container, Form Requests, validation rules, Eloquent mutators/casts, or queue workers without a wrapper or a rewrite. As a TPM, the correct architectural read is: pattern reference, not production component. The useful artifact inside the repo is the sanitizer/deduper composition (tagged sanitizer chain, normalization steps, duplicate-detection pass), which maps conceptually onto a Laravel-native pipeline (Form Requests → normalized DTOs via spatie/laravel-data → Eloquent casts → unique indexes/upsert → queued cleanup jobs).

Integration feasibility: Very low and not worth pursuing. Signals: 1 star, 0 dependents, README is a title only, maturity classified as "readme," and the description is demo-oriented ("clearly minimal reference implementation to adapt," "learning resource"). There is no documented install path, no versioning policy, no stated support model, and no evident test suite. Any real adoption path runs through reading the source and porting the approach — at which point you are not integrating the package at all.

Technical risk: High if treated as a dependency; low if scoped strictly as a spike input. Dependency-oriented risks: unmaintained code entering the production graph, Symfony/PHP version constraints that will not resolve against Laravel 11/12 on PHP 8.2+, demo fixtures or sample commands accidentally shipping, and no backward-compatibility commitments. The larger product risk is the one a TPM must own: sanitization and deduplication are silent-failure domains. Aggressive normalization or fuzzy matching can merge records that should have stayed separate, and there is no evaluation harness here to tell you whether that happened. The demo cannot de-risk that — your own labeled sample must.

Key questions:

• Is the real capability in the framework-agnostic endroid/data-sanitize library, and is that maintained? The demo bundle is the wrong artifact to evaluate regardless.
• What business rules define "clean" and "duplicate" — exact match, normalized match, fuzzy threshold, or business-key collision? Who signs off on the merge precedence rules?
• Are we solving one-off import cleanup or ongoing ingestion? That changes scope, ownership, and whether this is a spike or a workstream.
• What is the current pain: dirty imports, duplicate customer/account records, inconsistent entity naming, or encoding/whitespace noise?
• What is our tolerance for a false merge vs. a missed duplicate? Precision/recall targets need a product owner, not an engineer.
• Which system of record owns the canonical entity after a merge, and what downstream consumers read that ID?

Integration Approach

Stack fit: Assume custom glue only. The Laravel-native equivalents — which the team should validate during a spike rather than adopt from this repo — are Form Requests and custom Validator rules for input cleaning; DTO normalization (spatie/laravel-data) for shape/type coercion; Eloquent mutators and casts for canonicalization; database unique indexes and upsert/insertOrIgnore for duplicate prevention; and queued jobs with chunking for batch remediation. If any of the demo's sanitizer logic proves genuinely useful, wrap it in a first-party service or internal Composer package behind a Laravel service provider — do not pull the Symfony bundle.

Migration path: Do not install. Read src/ (commands, services, dependency-injection wiring) as executable documentation, extract the rules — trim, case folding, whitespace collapse, control-character stripping, email/phone shaping, blocking keys for dedupe — and reimplement in application code with tests. For existing dirty data, the migration artifact is a set of Artisan commands with dry-run mode, chunked iteration, row-level audit logging, idempotent retries, and a documented rollback script. Unique constraints get added only after the cleaned dataset passes review, not before.

Compatibility: Verify before any spike, but expect friction. Demo bundles from the Symfony ecosystem frequently target older PHP/Symfony combinations; even if Composer resolves, transitive Symfony components are dead weight in a Laravel app. The practical compatibility answer is: it does not need to be compatible, because the recommended path never installs it.

Sequencing:

1. Frame the business problem and success metrics with the stakeholders who feel the data pain (support, ops, finance, whoever owns the duplicate-account complaints).
2. Write the normalization and merge rules as a short spec — this is the TPM's primary deliverable here.
3. Time-box a one-week spike: read the repo, reimplement the approach natively against a copy of production data.
4. Build a labeled sample (a few hundred rows) and measure precision/recall on duplicate detection before touching production.
5. If the spike clears the bar, sequence: read-only audit command → dry-run remediation report → constrained write path → unique indexes → scheduled ingestion job.
6. Decide build-vs-maintained-library based on spike output, not on this package's suitability.

Operational Impact

Maintenance: Unacceptable as a dependency — with 1 star and 0 dependents, we would own 100% of it on day one, plus the Symfony-bundle-to-Laravel translation layer. If we fork or copy a bounded rule set under MIT, maintenance becomes tractable but still requires a named owner, unit tests, and a security review of any copied code. Budget for that owner explicitly; "no dependency" is not "no cost."

Support: None. No docs, no issue activity, no community, no versioning. Internal support from day one. Ramp-up cost sits entirely in reverse-engineering intent and validating behavior against our data — not in reading a bundle API.

Scaling: Demo code is not a scaling design. In-memory dedupe will not survive real volumes, and per-row sanitization that looks free becomes expensive at millions of rows once Unicode normalization and fuzzy comparison enter the picture. Production shape is chunked queued jobs, indexed lookups, blocking keys to shrink the comparison space, and database-enforced uniqueness. Set explicit performance budgets (rows/minute, memory ceiling, job wall-clock) before committing to a design.

Failure modes: The one to manage is silent data corruption from bad merges — wrong records combined, canonical IDs reassigned, downstream joins broken, and nobody notices for weeks. Supporting cast: partial import failures, timeout and memory exhaustion, unique-constraint violations surfacing mid-migration, normalization collisions (two genuinely distinct records folding to the same key), encoding artifacts, non-idempotent retries creating duplicates, and demo fixtures leaking into a real dataset. Every remediation path needs dry-run output, sampled human review, row-level audit logs, transaction boundaries, and a rehearsed rollback.

Ramp-up: Low for a Laravel team using native validation, casts, indexes, and queues — and high for anyone who tries to learn Symfony bundle conventions to make this work. Direct the team's ramp-up at the business rules and the data-quality test cases, not at the demo. TPM posture to record in the decision log: reference implementation for a time-boxed spike; explicitly rejected as a production dependency; spike output to return a build-vs-maintained-library recommendation with a precision/recall evaluation and an effort estimate.