Validation Laravel Package

Technical Evaluation

Architecture fit

runn/validation is not a Laravel package. It is a framework-agnostic PHP validation and sanitization library from the Runn Me! family — no service provider, no facade, no publishable config, no Validator contract implementation, no Laravel-aware exception type. Any assessment that treats it as a drop-in Laravel validation replacement is misframed.

The realistic fit is narrow but legitimate: a domain-layer invariant checker sitting behind Laravel's HTTP boundary. Laravel's FormRequest/Validator remains responsible for request shape, auth-scoped rules, and user-facing messages; runn/validation would own sanitization and business-rule validation inside a bounded context, where its value-object and contract-oriented design is a better conceptual match than Laravel's string-keyed rule arrays. That is a hexagonal/DDD posture, and it only pays off if the team has already committed to that layering. In a conventional Laravel CRUD codebase this library adds a second validation vocabulary with no offsetting benefit.

Integration feasibility

Composer install is trivially feasible; everything after that is bespoke work:

• A service provider to register validators/sanitizers in the container.
• An adapter translating its error collection into Laravel's MessageBag/ValidationException so the existing exception handler and front-end error rendering keep working.
• A localization layer, since message catalogs are almost certainly not wired to Laravel's lang/ files.
• Boundary tests confirming sanitizer output is what the rest of the app expects (idempotency, type coercion, null/empty handling).

Rough order of magnitude: low single-digit engineer-weeks for a production-grade adapter with tests — not because the library is complex, but because none of it exists.

Technical risk

This is where the package fails as a default choice:

• Adoption signal is near-zero. 10 stars, 0 dependents. The overall score of 0.17 reflects readiness, not the value of the problem space (the 4.92 opportunity score confirms validation is high-value — this package is simply not the vehicle).
• Bus factor of one, possibly zero. The Runn Me! ecosystem appears dormant; documentation is thin and partly non-English. Assume no upstream fixes.
• LGPL-3.0. Workable in a commercial Laravel product, but it introduces a compliance obligation the team must consciously own (relinking rights, no static/vendored-and-modified distribution without source). Most Laravel shops default to MIT/Apache and have no process for this. This alone can stall procurement or legal review.
• PHP version drift. No published support matrix against current PHP or Laravel releases; a PHP 8.x upgrade could strand the dependency.
• Security surface. Validation and sanitization are security-adjacent. An unmaintained library handling regex-based rules is a ReDoS and silent-pass risk with no disclosure channel.

Key questions

1. What is the last commit date and PHP constraint in composer.json? Does it install cleanly on our PHP/Laravel target?
2. Does it expose any Laravel-compatible error or message contract, or is the adapter 100% on us?
3. Is the repository archived? If not, who is the responsive maintainer, and what is the commit cadence over the last 24 months?
4. Has Legal signed off on LGPL-3.0 in a distributed or SaaS product, and do we have a fork-and-maintain policy if not?
5. Do the sanitizers mutate input or return new values, and are they idempotent and type-safe on null/array/object input?
6. Which specific rules do we need that Laravel's validator cannot express? If the answer is "none," this evaluation ends here.

Integration Approach

Stack fit

Installable in any Composer project on a supported PHP version. Architecturally it belongs in the domain/application layer, consumed by domain services and value objects, never by controllers. The HTTP edge keeps FormRequest; the domain edge gets a thin Validator port implemented by a RunnValidationAdapter. This keeps the dependency swappable — the single most important design decision given the maintenance risk.

Migration path

Do not migrate. There is no migration path from Laravel's validator to this library, and attempting one trades a supported, documented, localized, well-understood component for an unsupported one. The only defensible adoption is greenfield, incremental, and contained: introduce the library in one new bounded context where domain-level sanitization is genuinely needed, behind the port above, and leave every existing FormRequest untouched.

Compatibility

Three checks gate any further work:

1. composer why-not runn/validation against the current lockfile — confirm no PHP constraint conflict with the Laravel version in use.
2. LGPL-3.0 compatibility with the distribution model (SaaS vs. shipped artifact) — Legal sign-off before code is written.
3. Adapter coverage — error translation, localization, and exception mapping must be proven by tests before the pilot goes beyond one context.

Sequencing

1. Spike (1–2 days). Install, write one real validator and one sanitizer, confirm PHP compatibility and error ergonomics.
2. Legal/compliance gate. LGPL determination and fork policy. Hard stop if unresolved.
3. Adapter build. Service provider, Validator port, error-to-MessageBag translation, localization, boundary tests.
4. Single-context pilot. One bounded context, behind a feature flag, with Laravel validation still at the edge as a safety net.
5. Decision review. Compare defect rate, developer ergonomics, and maintenance load against a hand-rolled domain validator (~200 lines, MIT, fully owned). This is the real competitor and it will often win.

Operational Impact

Maintenance

Treat the package as vendored code we own. Realistic steady state: a fork in our VCS, a named internal owner, and a standing commitment to patch PHP-version and security issues ourselves. If the organization cannot fund that, do not adopt. The 0-dependents figure means no upstream community will absorb this work.

Support

None. No vendor, no active community, no security disclosure process, no issue-triage SLA. Escalation is internal, full stop. Budget an SME who understands the library's idioms — that person is a single point of failure until a second engineer is trained.

Scaling

Runtime cost is negligible and not a scaling concern: validation is per-request, CPU-bound, and dominated by whatever rules are configured. The scaling risk is organizational, not technical — the number of bounded contexts depending on an unmaintained library grows monotonically while the maintenance capacity does not. Cap adoption explicitly (e.g., "no more than two contexts") or the dependency footprint will outgrow the willingness to replace it.

Failure modes

• Silent pass. Unrecognized input types or rule misconfiguration validate as true rather than erroring. Highest-severity mode; mitigate with type-strict boundary tests and fail-closed configuration.
• Upgrade break. PHP or Laravel minor upgrade breaks the dependency; no upstream patch exists. Mitigate via fork and a lockfile-pinned CI matrix.
• Unlocalized or malformed errors leaking to users. Mitigate in the adapter, not the library.
• ReDoS via regex rules. Mitigate with input length caps and a rule allowlist.
• Compliance drift. Fork modifications distributed without LGPL source availability. Mitigate with a documented release checklist.
• Abandonment-with-CVE. No disclosure channel means we discover issues by accident. Mitigate with periodic dependency audit and a pre-agreed exit.

Ramp-up

Moderate for a small library. Engineers familiar with Laravel's validator will need a mental model shift to contract/object-oriented validation, and the thin, partly non-English documentation slows the first week. Estimate 3–5 days to productive, plus the adapter work before anyone can ship. Weigh that against the alternative: a hand-rolled domain validator using Laravel's own rule objects, which ramps in hours, carries no license obligation, and is fully owned — for most teams that is the better trade, and this package's low readiness score is the reason why.