Validation Laravel Package

Technical Evaluation

Architecture fit: Unchanged in principle. Rakit Validation remains a good fit where we need Laravel-style, rule-based validation without adopting Laravel: small apps, shared PHP libraries, legacy services, and non-framework components. It is an in-process library with no runtime services, so it does not add a validation platform to the architecture. It remains a weaker fit for teams already on current Laravel. The v1.0.0 release adds file-upload validation (mimes, uploaded_file for multiple files, file-size support in min/max/between), which modestly widens the addressable use cases to include form and upload handling outside Laravel.

Integration feasibility: Still feasible via Composer, and now with better signals of active maintenance: a 1.0.0 release, PHP_Codesniffer adoption, typehints, and PHPDoc improvements. The release notes also make the canonical repository explicit (rakit/validation on GitHub), which closes the biggest provenance gap in the prior assessment. The remaining blocker is the runtime support matrix: the release raises the PHP floor only from 5.5 to 7.0, which tells us the tested baseline but says nothing about PHP 8.x. All of PHP 7.0–7.3 are end-of-life, so "supports 7.0+" must not be read as "supports our production runtime." A time-boxed spike on our actual PHP versions remains mandatory before commitment, covering representative rules, nested/wildcard inputs, custom closures, localized messages, and the new file-upload rules.

Technical risk: Medium (down from medium-high). The project is demonstrably not abandoned, has a permissive MIT license, and now shows hygiene investment (coding standard, typehints, PHPDoc), which lowers the internal-fork and static-analysis burden. Risk does not drop to low because v1.0.0 is a major release with breaking changes: ErrorBag::firstOfAll() now returns an associative array instead of an indexed array, Rule::check() must return bool, the default rule now mutates empty values via the ModifyValue trait, and uploaded_file messages/behavior are dynamic. Any existing or future consumer pinned to 0.x will break on upgrade in ways that are silent at the call site. Treat Laravel parity as API-compatible, not behavior-identical, and keep the package behind an internal validation interface so it stays replaceable.

Key questions:

• Which PHP versions are actually in the CI matrix for v1.0.0, and is PHP 8.x tested and supported, not merely tolerated?
• Is there a published support policy and release cadence now that 1.0.0 exists, or was this a one-off release?
• What is the security disclosure process, and is there an active maintainer roster?
• Do we have any 0.x consumers, and have they been assessed against the firstOfAll(), Rule::check(), and default-rule behavior changes?
• Does the default rule's value mutation affect our downstream code paths that assumed values were only validated, not modified?
• How close is rule and error-message parity to the Laravel versions we know, including the new dynamic messages for in/not_in and uploaded_file?
• Will we consume upstream, vendor a fixed copy, or maintain an internal fork, and who owns that decision?
• Alternatives re-check: native framework validation, Symfony Validator, Respect\Validation, or a thin internal rule engine.

Integration Approach

Stack fit: Best suited to Composer-based PHP services outside Laravel, shared libraries that cannot depend on illuminate/validation, and legacy codebases where replacing input handling is expensive. The new file-upload rules make it viable for upload-handling services that previously needed a different library. If the application is Laravel 8+, still use the framework validator unless framework independence is an explicit requirement.

Migration path: Introduce through an adapter, not direct static calls. Define an internal ValidatorInterface with our own error shape, implement it with Rakit, and keep the mapping in one place so the v1.0.0 breaking changes are absorbed at a single boundary rather than scattered across call sites. Any existing 0.x usage must be upgraded deliberately: audit for firstOfAll() consumers (indexed to associative array), custom rules whose check() returns truthy non-booleans, and any code relying on the default rule not modifying values. Pilot on new or low-risk paths first; run Rakit and the incumbent validator in parallel for critical forms before cutover.

Compatibility: Pin an exact version (or internal fork); do not float, and do not allow a 0.x/1.x mix in the same estate. Add CI coverage for every PHP version we actually run in production, plus static analysis (the new typehints and PHPDoc make this materially more useful than before) and representative locale files. Explicitly regression-test: nested field handling, wildcard expansion, custom rule exception behavior, firstOfAll() shape, default-rule mutation, multi-file uploaded_file, and file-size rules against $_FILES-style payloads.

Sequencing:

1. Re-confirm provenance, license obligations, PHP support matrix, and maintenance status for the 1.0.0 line.
2. Inventory any existing 0.x usage and triage the three known breaking changes.
3. Run a short spike on target PHP versions with representative rules, nested inputs, and the new upload rules.
4. Build/refresh the adapter and contract tests, including firstOfAll() and default-rule semantics.
5. Pilot on one low-risk endpoint or library boundary.
6. Expand only after error parity and performance are accepted.
7. Set the sustainment model (upstream tracking, vendored snapshot, or internal fork) and define exit criteria if PHP compatibility breaks again.

Operational Impact

Maintenance: We should still assume ownership, but the burden is lighter than previously assessed: an active 1.0.0 release, coding-standard enforcement, and typehints reduce the patch effort for PHP upgrades. Budget for periodic compatibility checks and dependency scanning. A 1.0.0 line also gives us a defensible semver contract to pin against, which the stale 0.x line did not. Do not adopt without a named internal owner.

Support: Still no commercial support identified. Upstream responsiveness is likely better than assumed in the prior assessment but unproven; issue backlog and response times should be sampled before we depend on them. Support remains internal documentation, approved patterns, and on-call triage for validation errors.

Scaling: Unchanged. Validation runs in-process and scales horizontally with the application. Watch CPU and memory for complex regex rules, large payloads, and nested wildcard expansion. The new file-related rules add a new consideration: enforce upload size limits and validate before loading file contents, so validation does not become a memory or denial-of-service vector.

Failure modes: Largely unchanged, with additions. Previously identified: missing locale files, PHP deprecation warnings becoming errors, malformed rule strings, custom rule exceptions, inconsistent error shapes, silent divergence from Laravel behavior. New for 1.0.0: consumers indexing into firstOfAll() output, custom rules returning non-boolean values from check(), and code paths that assumed the default rule did not mutate values. Critical forms should fail closed and carry regression tests for each of these.

Ramp-up: Low for developers familiar with Laravel validation; medium for others due to custom rules, nested dot notation, and wildcard behavior. The added helper methods (Helper::join, Helper::wraps), TranslationsTrait, and Rule::setParameterText reduce custom-message boilerplate and modestly lower the ramp-up for localized error output. A small internal guide covering approved patterns, the 1.0.0 breaking changes, and file-upload examples will curb misuse.