Validation Laravel Package

Technical Evaluation

Architecture fit

• siriusphp/validation is a deliberately framework-agnostic validator: standalone rule objects, a Validator entry point, and no coupling to HTTP, containers, or templating. That is a strength in a hexagonal/DDD codebase and a liability in an opinionated framework like Laravel.
• Laravel's validation layer is not just a rule engine — it is wired into FormRequests, $request->validate(), the ValidationException → 422/redirect handling, the $errors bag, Blade directives, localization via lang/*/validation.php, and php artisan make:request. Adopting siriusphp means either bypassing that pipeline or writing an adapter that re-implements it.
• Net: architecturally viable only as a domain-layer validator inside a bounded context that must not depend on illuminate/*. As an HTTP-boundary replacement for Laravel validation, it is a poor fit.

Integration feasibility

• Composer-installable, MIT, no framework service provider shipped — you write your own binding and resolve it from the container.
• Technically straightforward to wrap behind a ValidatorInterface port and inject it into domain services. The friction is not installation; it is the seam between siriusphp's error model (rule-keyed message arrays) and Laravel's MessageBag/ValidationException contract.
• Every Laravel-native feature you currently get for free — bail, sometimes, Rule::when, nested array wildcards, DB-backed rules (unique, exists), custom rule objects, after-hooks — must be re-created or abandoned.

Technical risk

• Unmaintained: last release 2022-09-21, ~158 stars. Effectively a dormant dependency. Verify the composer.json PHP constraint against your target (Laravel 11/12 require PHP 8.2+); PHP 8.3/8.4 deprecations are unaddressed upstream.
• Duplication of a solved problem: Laravel ships a mature, actively maintained validator. Introducing a second validation paradigm creates two sources of truth for rules, messages, and locale files.
• Behavioral drift: null/empty-string handling, nested-array semantics, and message formatting differ from Laravel's. Silent divergence in edge cases is the highest-probability defect class.
• Bus factor: single-maintainer history with no recent activity; you inherit ownership on adoption.

Key questions

1. What specific gap in illuminate/validation does this close? If the answer is "none, we want framework independence," is the isolation worth a self-maintained dependency?
2. Does the package's PHP constraint and test matrix cover your runtime (8.2/8.3/8.4)?
3. Is there an active maintainer or viable fork path, and who owns it internally?
4. Would respect/validation, symfony/validator, or a thin in-house domain validator be a better-maintained fit for the same isolation goal?
5. What is the localization requirement — does siriusphp cover your target locales, or will you author message catalogs?

Integration Approach

Stack fit

• Fits only as an inner-layer dependency: domain services, value objects, and commands that must remain framework-agnostic. It does not fit the HTTP request lifecycle, FormRequests, or API Resource validation.
• Recommended pattern: define a DomainValidator port in your application layer, implement it with siriusphp, and keep Laravel's validator at the HTTP boundary for transport-level concerns (types, presence, auth-scoped uniqueness).

Migration path

• Do not migrate existing validation. Retrofitting siriusphp across a codebase with 158-star, 2022-vintage tooling is a high-cost, negative-ROI rewrite.
• Bounded adoption: pick one new domain module, implement its invariants in siriusphp behind the port, and leave controllers on Laravel validation.
• If the driver is genuinely framework independence (e.g., a shared domain package consumed by a non-Laravel service), evaluate this alongside symfony/validator and respect/validation in the same spike — the decision should be comparative, not default.

Compatibility

• Namespace-isolated from illuminate/validation; no autoload conflict expected. Composer resolution is the main risk vector (PHP constraint and any transitive pinned dependencies).
• Message catalogs and locale handling are separate from Laravel's lang/ tree — plan for two translation pipelines or a shared abstraction.

Sequencing

1. Spike (1–2 weeks): validate PHP 8.3/8.4 compatibility, run the existing test suite, and diff rule behavior against Laravel's validator for the rules you actually use.
2. Decision gate: compare against symfony/validator and respect/validation on maintenance, rule coverage, and message i18n. Default to Laravel's validator if the isolation requirement is not concrete.
3. Adapter: build the port + implementation + a MessageBag bridge so the choice remains reversible.
4. Pilot: one bounded context, one team, with a documented rule inventory.
5. Review: measure defect rate from behavioral divergence before any second consumer onboards.

Operational Impact

Maintenance

• Treat as vendored code. Budget ownership: patch PHP-version deprecations, security advisories, and rule gaps internally, or fork under your org with a maintained release cadence.
• Two validation systems means two rule inventories, two message catalogs, and two onboarding paths. That tax compounds with team size.

Support

• No vendor, no SLA, minimal Stack Overflow footprint, small issue backlog. Internal documentation and a named owner are prerequisites, not nice-to-haves.
• Upgrade support is effectively zero — every Laravel or PHP major upgrade requires you to verify the package yourself.

Scaling

• Runtime cost is negligible; validation is not a throughput bottleneck at typical request volumes. If anything, siriusphp's lighter rule set is marginally faster than illuminate/validation — not a decision-relevant factor.
• The real scaling constraint is organizational: every new engineer must learn a non-idiomatic validation DSL that they cannot transfer to the next Laravel project.

Failure modes

• Silent divergence: rules accept/reject inputs differently than Laravel's equivalents (empty strings, null, nested keys, numeric strings) — produces bad data or spurious 422s.
• Uncaught exception type mismatch: siriusphp throws its own exception; unhandled, it surfaces as a 500 instead of Laravel's 422/redirect contract.
• PHP upgrade breakage: deprecation warnings become errors on the next major bump, with no upstream fix.
• Localization gaps: untranslated messages leak into user-facing responses.
• Dependency rot: abandoned transitive dependency or a security advisory with no patch path.

Ramp-up

• Laravel developers are already productive with the native validator; siriusphp costs 1–2 days per engineer for the DSL plus ongoing context-switching between two paradigms.
• Net recommendation: do not adopt in a Laravel codebase absent a concrete, documented framework-independence requirement. If that requirement exists, run the comparative spike against symfony/validator and respect/validation first — the 1.83 score and 2022 release cadence make this a difficult default to justify.