Data Sanitize Demo Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for data hygiene: This is not a credible buy candidate. endroid/data-sanitize-demo-bundle is a demo bundle — 1 star, 0 dependents, readme-only maturity, and a Symfony bundle rather than a Laravel package. Its PM value is as a reference implementation to size an internal data-cleaning/dedup capability, not as a dependency to adopt.
• Feature scoping for deduplication and normalization: The demo illustrates the shape of the pipeline — normalization, matching, merging, duplicate removal — which helps define acceptance criteria (match confidence thresholds, merge/precedence rules, audit trail, dry-run behavior) for a first-party feature.
• Roadmap triage on data quality: If customers repeatedly hit duplicate records, inconsistent entities, or dirty imports, this is a signal to prioritize a data-quality workstream. Use it to frame whether that ships as user-facing product surface (merge tools, dedup review UI) or as an internal ops/admin capability.
• Platform vs. product boundary: Sanitization is cross-cutting. The demo supports the decision to place normalization and dedup logic in a shared internal package or service rather than embedding it in one application.
• Spike input, not architecture: Cheap, low-risk input to a time-boxed discovery spike. It is not a basis for architecture decisions, because there is no test suite, versioning, Laravel integration, or maintenance signal.

When to Consider This Package

Consider it when:

• You are running a short, disposable spike to understand what data sanitization and deduplication involve in a PHP codebase.
• You need a teaching reference to align product and engineering on terminology — normalization, blocking, fuzzy matching, merge policy — before writing an RFC.
• You want a concrete illustration of pipeline stages to ground acceptance criteria and effort estimates.
• The team is Symfony-native and can read the bundle directly as documentation (Laravel teams should still treat it as a reference only).

Look elsewhere when:

• You need production code. One star, zero dependents, no releases, no tests, no support model — adopting it is a liability with no offsetting upside.
• You are on Laravel. Laravel does not load Symfony bundles; it uses service providers, package discovery, facades, and config publishing. Any integration is custom glue with zero upstream support. Prefer Laravel-native mechanisms (Form Requests, Validator, Eloquent casts/mutators, upsert/insertOrIgnore, queued jobs, spatie/laravel-data) or framework-agnostic libraries.
• You need deduplication at scale. Demo bundles typically use naive comparison; production dedup needs indexing/blocking strategies, performance budgets, and a labeled evaluation dataset.
• You need compliance or auditability around merged records — no governance, logging, or rollback features are evidenced here.
• The underlying capability lives in endroid/data-sanitize itself; evaluate that library directly and wrap it, rather than pulling in the demo.

Recommended posture: Treat as documentation. Install nothing, pin nothing, vendor no code beyond an explicit reviewed extraction. If the capability is real roadmap work, budget a first-party build or evaluate maintained alternatives with an explicit evaluation harness.

How to Pitch It (Stakeholders)

To executives: This is a demo, not a product — one star, no dependents, no release maturity, and it targets Symfony rather than our Laravel stack. We should not take a dependency on it. What it is useful for is a cheap, low-risk way to estimate the cost of solving data duplication and dirty imports, which is a recurring customer complaint. Recommendation: fund a short discovery spike using it strictly as a reference, then decide build vs. maintained-library based on the spike output — not on this package's suitability.

To engineering: Use it as a reading reference during a time-boxed spike; do not install it. It is a Symfony demo bundle, so any Laravel work is custom integration, and you should assume no tests, no semantic versioning, no upstream support, and possibly stale PHP/Symfony constraints in composer.json that conflict with Laravel 10/11 on PHP 8.1+. Extract the approach — a tagged sanitizer chain (trim, normalize email/phone, collapse whitespace, strip control characters), a dedupe pass keyed on normalized values, merge rules — and validate it against our own data using Laravel-native validation, Eloquent normalization, database unique constraints, and chunked queued jobs with dry-run and row-level audit logging. Return with an effort estimate, a preferred maintained library or build plan, and a data-quality evaluation approach (precision/recall on a labeled sample, plus a rollback plan) before we commit. Flag any copied code for security/legal review — MIT permits a fork but does not reduce ownership burden.