Validation Laravel Package

Product Decisions This Supports

• Build vs. buy vs. use-native for validation. This package sits in the same decision space as Laravel's built-in Validator, spatie/laravel-data, respect/validation, and Symfony's Validator component. Evaluating it forces an explicit answer to "what does our validation layer actually need that the framework doesn't give us?"
• Where validation lives in the architecture. runn/validation is framework-agnostic, which makes it relevant to a real product question: should validation rules live in the HTTP layer (FormRequests) or in the domain layer so they can be reused by console commands, queue workers, imports, and webhooks? If your roadmap includes bulk import, partner API ingestion, or CLI tooling, domain-level validation becomes a genuine architectural decision rather than a style preference.
• Sanitization as a first-class concern. The package couples validation with sanitization (normalize-then-validate). This supports decisions about data hygiene at ingestion boundaries — trimming, coercion, and canonicalization before persistence — which matters for data quality, deduplication, and downstream analytics.
• Roadmap signal, not adoption signal. The category-level "opportunity" score (4.92) says validation/sanitization is a high-demand problem area. That is a reason to invest in a validation strategy; it is not evidence that this implementation is the right vehicle.
• Explicit anti-decision. Concluding "we evaluated and declined" is a legitimate and valuable product output — it closes the loop for engineering, prevents repeated re-evaluation, and documents the rationale for the next person who finds this repo.

When to Consider This Package

Adopt only under a narrow set of conditions, ideally all of them:

• You are not building on Laravel (or you deliberately want validation outside the framework). This library has no Laravel service provider, no facade, no config publishing, no translation integration, and no Validator-compatible API. In a Laravel app, every ergonomic benefit — $request->validate(), Rule:: objects, localized messages, testing helpers — is something you would rebuild yourself.
• Legal has cleared LGPL-3.0 for your distribution model. LGPL in a Composer dependency is a real review item for commercial and closed-source products. Budget for counsel time; do not treat it as a footnote.
• You are prepared to vendor or fork it. With 10 stars, 0 dependents, and a low composite score, you are effectively the maintainer. If the answer to "what happens when this repo goes quiet?" isn't "we own it," you have your answer.
• You have a specific capability gap the alternatives don't cover — for example, a need for the sanitize-and-validate pipeline in a non-HTTP, non-Laravel service that shares your monorepo.

Look elsewhere when:

• You're in a standard Laravel application. Use the native Validator and FormRequests; reach for spatie/laravel-data for typed DTOs, or respect/validation / Symfony Validator (via a bridge) if you need framework-agnostic rules with far larger communities.
• You need a maintained dependency with a security response process. Low adoption means no crowd-sourced bug discovery and no expectation of timely CVE handling.
• You need an integration surface — translations, custom rule registration, testing assertions, IDE support — because you'd be writing all of it.
• Your team's time is the scarcest resource. The integration cost here is likely larger than the rule-writing cost it saves.

How to Pitch It (Stakeholders)

Bottom line: do not adopt. The category is worth investing in; this package is not the way to do it.

For executives: We evaluated runn/validation, an open-source PHP validation and sanitization library, as a potential dependency. Recommendation is to decline. It has negligible adoption (10 stars, zero dependent projects), a copyleft-family license (LGPL-3.0) that would require legal review before shipping in a commercial product, and no integration with our framework — meaning we would build the integration ourselves and then own the library, since there is no realistic upstream support. The functional need it addresses is already covered at zero cost and zero risk by framework-native tooling and well-maintained alternatives. Adopting it would add legal review effort, supply-chain exposure, and maintenance burden in exchange for capability we effectively already have.

For engineering: This is a small, framework-agnostic validate-and-sanitize library. There's no service provider, no facade, and no Laravel-facing API, so the realistic work is "write our own adapter, then own the dependency." It's a single-maintainer project with no dependents — treat it as a fork, not a dependency. If the underlying idea (sanitize-then-validate, domain-layer rules reusable across HTTP, queues, and CLI) is what appeals to you, that's a pattern worth adopting; the library is not required to adopt it. Recommend the native Validator for HTTP boundaries and spatie/laravel-data for typed DTO validation, and revisit a shared domain-validation layer as a first-party abstraction if the import and webhook work on the roadmap materializes. Worth restating the one durable takeaway: validation demand is high, and our current answer is scattered — that's worth a spike, just not this dependency.