Sanitizer Laravel Package

Technical Evaluation

Architecture fit

• Sanitization is a cross-cutting input-boundary concern, and this package sits precisely there: a SanitizedRequest extending Laravel's FormRequest, plus a standalone Sanitizer service/facade for non-HTTP ingestion.
• The separation it encourages — normalize first, validate second, keep controllers thin — is architecturally sound and consistent with how Laravel apps are usually layered.
• The marginal value is capped, however: Laravel's native FormRequest::prepareForValidation() has covered roughly the same use case since 5.5. The package is a convenience layer, not a capability layer.

Integration feasibility

• In a Laravel 7 app: low effort. Composer require, publish config, extend the sanitized request base, declare $filters. A developer can be productive in a day.
• Outside Laravel 7: feasibility collapses. The illuminate/* constraints are the gate; resolution conflicts are likely on Laravel 9+ and on PHP 8.2+ estates.
• Zero dependents and a zero score mean effectively no ecosystem validation — we would be an early, near-only adopter, with no field reports to lean on.

Technical risk

• High, and concentrated in lifecycle rather than code quality. Upstream is effectively unmaintained; Laravel 7 reached end of life in March 2021, and the package targets that era. No security response, no PHP 8.x guarantees.
• Silent mutation risk. Sanitizers rewrite request input before validation, so what validation sees, what logs record, and what gets persisted can silently diverge. That is a meaningful audit and debugging burden.
• Ordering semantics. Filter-before-validate means a value can pass a rule only because it was cast or trimmed first. Surprising behavior is easy to introduce and hard to trace.
• Mitigating factor: MIT license and a small surface area make forking legally and technically viable. The risk is ownership, not legality.

Key questions

• What Laravel and PHP versions must we support over the next 12–24 months? If anything above 7, this is a fork decision, not an adoption decision.
• Is sanitization driven by a compliance obligation (PII, PCI, data residency) that requires a documented, auditable pipeline? That changes the bar for "good enough."
• Do we need sanitization outside HTTP requests — queues, CLI imports, webhooks? If not, native prepareForValidation() plus middleware likely suffices.
• Who owns the code and its test suite if we fork, and what is the exit date?
• Is there an approved maintained alternative — DTO/mapping libraries, a thin internal sanitizer registry, or custom middleware?

Integration Approach

Stack fit

• Clean fit only for Laravel 7-era applications on PHP 7.x with no near-term framework upgrade on the roadmap.
• Poor fit for Laravel 9/10/11 estates or PHP 8.2+ targets; expect composer resolution conflicts and framework-upgrade blockage.

Migration path

• Preferred: port the required behavior into a project-owned base request class using prepareForValidation(), or a small internal sanitizer registry. This removes the dependency entirely.
• If the package's specific filter vocabulary is already relied upon: fork it (small, MIT), vendor it under an internal namespace, and carry tests with it.
• Do not introduce it into greenfield code, and do not introduce it in the middle of a framework upgrade — sequence the upgrade first, then decide.

Compatibility

• Pin exact versions and freeze them in composer.lock; add a CI gate that fails if a framework upgrade cannot resolve.
• Add an architecture test asserting the package namespace is only referenced at the request boundary, so it can be swapped or removed in one place.

Sequencing

1. Confirm the target Laravel/PHP matrix and whether the application is frozen or upgrading.
2. Prototype the sanitization rules for one or two real request classes — not a synthetic sample.
3. Implement the same rules natively via prepareForValidation() and compare cost, clarity, and test coverage.
4. Choose the lighter path. If the package wins, wrap it behind an internal interface, unit-test each filter, and document filter ordering explicitly.
5. Register the decision as technical debt with an owner, a removal criterion, and a review date tied to the next framework upgrade.

Operational Impact

Maintenance

• Upstream is effectively unmaintained, so adoption transfers ownership of patches, PHP version bumps, and any security fixes to us. The codebase is small enough that this is bounded, but it is permanent and non-zero until the dependency is removed.

Support

• No dependents, no active issue triage, no community answers. Internal runbooks and a named owner are mandatory. Institutional knowledge will concentrate in whoever performs the integration, which is a single-point-of-failure pattern.

Scaling

• Runtime cost is negligible — per-request string transforms. No impact on throughput, horizontal scaling, or infrastructure sizing. All the risk here is operational, not performance.

Failure modes

• Silent over-sanitization destroying legitimate values (unicode handling, aggressive trimming, unexpected casting).
• Divergence between sanitized and original input across logs, validation, and persistence — the hardest class of bug to diagnose after the fact.
• Validators passing or failing unexpectedly due to filter ordering.
• Unpatched code breaking on a future PHP minor through deprecations or type-coercion changes.
• Fork drift if we patch locally and later attempt to resync with upstream.

Ramp-up

• Low skill barrier. Any Laravel developer grasps FormRequest semantics in hours, and the package adds little novel API surface.
• The real ramp-up cost is contextual: every new joiner needs the "why are we on an end-of-life package, and what is the exit plan" briefing. Document the decision record, the fork provenance, and the removal date alongside the code.

Net position: treat this as a stopgap at best. Prefer native prepareForValidation() where the target framework allows; if the specific filter behavior is genuinely required, fork and vendor it with a dated exit tied to the next Laravel upgrade. Do not adopt for new work — the opportunity is small and the lifecycle liability is not.