Sanigen Laravel Package

Technical Evaluation

Sanigen is a Laravel/PHP sanitization package that fits naturally into Eloquent-centric applications needing deterministic, type-safe cleanup of user-supplied strings. v1.9.0 materially improves its architecture fit for modern Laravel apps: structured recursive sanitization across ordinary attributes, JSON columns, and Spatie Translatable fields; compiled single-pass rule processing; dot-notation and wildcard paths for heterogeneous JSON; Unicode NFC and newline normalization. The package remains a library-level concern rather than an infrastructure dependency, so architectural coupling is low.

Integration feasibility is high for teams already on Laravel and Eloquent. The new HasSanitizedTranslations trait makes Spatie Translatable support real rather than custom glue. The deprecation of the recursive: prefix is backward-compatible but signals future major-version work; existing rule sets should still function. The most important behavioral change is that root sanitizer rules now recurse automatically and each string leaf receives exactly one matching pipeline. That is a semantic improvement, but it can alter output for existing configurations that relied on the old non-recursive behavior, so upgrade testing is required.

Technical risk is moderate but manageable. Security posture improves through shared depth, item-count, and scalar-length limits; fail-closed handling for objects, resources, malformed paths, and equal-specificity conflicts; and atomic structured processing that avoids leaking submitted values in exceptions. The main risks are behavioral drift in existing sanitization rules, unclear observability when sanitization fails closed, and potential performance cost on large JSON payloads despite the single-pass engine. The 138 tests and 405 assertions are a positive signal but not a substitute for application-specific regression coverage.

Key questions: Which PHP, Laravel, and Spatie Translatable versions are supported? How are custom sanitizers registered and ordered relative to built-in aliases? What exactly happens when fail-closed conditions occur — exception type, logging, and validation integration? Does the package sanitize before or after Laravel validation, and how should teams handle arrays of DTOs or nested objects? Are depth/item limits configurable per model or globally? What is the compatibility window for the deprecated recursive: prefix?

Integration Approach

Stack fit is strong for Laravel applications using Eloquent attributes, JSON casts, and Spatie Translatable. The package should sit in the write path — model events, form requests, or a dedicated sanitization service — before persistence. The new structured engine reduces the need for custom recursive walkers in application code, which is the primary TPM-level benefit: less bespoke sanitization logic to maintain and audit.

Migration from v1.8.x to v1.9.0 should be incremental. First, upgrade the package and run the existing application test suite against representative payloads, especially JSON columns and translatable fields, because root rules now recurse automatically. Second, keep the recursive: prefix in existing rules during the transition; it remains compatible. Third, introduce dot-notation and wildcard rules only for known heterogeneous JSON shapes, and add HasSanitizedTranslations where Spatie Translatable is already in use. Fourth, remove deprecated prefixes in a later cycle, not as part of the initial upgrade.

Compatibility review should confirm PHP/Laravel/Spatie version constraints and whether the package’s service provider and configuration publishing align with the application’s existing config cache and deployment process. Sequencing should be: dependency upgrade, non-production regression run, targeted JSON/translation test coverage, canary or staging rollout, then production enablement. Historical data does not need backfilling for write-path sanitization, but teams that want consistent stored data should plan a separate batch sanitization job with the same limits and failure handling.

Operational Impact

Maintenance overhead is expected to be low to moderate. The package is small and focused, but the v1.9.0 behavioral changes mean rule sets should be owned and reviewed like application code. The deprecation of recursive: creates a future maintenance task, not an immediate break. Support depends on the package’s release cadence and documentation; teams should pin versions and review changelogs before minor upgrades because sanitization semantics can shift.

Scaling characteristics improve through the compiled single-pass engine and shared traversal limits, which help contain CPU and memory exposure on nested payloads. However, large JSON documents and wide translation sets still require monitoring: sanitization is synchronous in the request path unless the team moves it to a job. Failure modes include fail-closed rejection of malformed paths or equal-specificity conflicts, exceptions that intentionally omit submitted values, and silent rule mismatches if aliases are misconfigured. Teams should log sanitization failures with correlation IDs rather than payload contents.

Ramp-up is moderate. Engineers need to understand rule precedence, alias behavior, dot-notation versus wildcard matching, and the new automatic recursion model. A short internal guide plus representative test fixtures will reduce confusion. Operationally, the package is a good fit for teams that want deterministic, type-safe sanitization without building and maintaining a custom recursive sanitizer, provided they treat rule configuration as production code and validate upgrades against real payloads.