Validate Laravel Package

Product Decisions This Supports

• Build vs. buy for validation layers: psx/validate is a useful reference implementation of a declarative filter/rule pipeline (compose named filters into a validation chain, apply against structured input). It informs whether to build an in-house rule engine or adopt an existing validator rather than settling the question on its own merit.
• API/schema validation strategy: The filter-system approach maps well to decisions about validating request payloads against a schema contract — relevant if the roadmap includes typed API contracts, OpenAPI-driven validation, or a public/partner API surface.
• Feature scoping for data ingestion: If the roadmap has CSV imports, webhook receivers, or third-party data syncs, this package's filter composition model is a useful pattern to spec against: reusable rules per field, composable, testable in isolation.
• Roadmap input, not roadmap driver: Its low adoption (1 star, 0 dependents) means it should influence design thinking, not anchor a delivery commitment. Treat as prior art in a spike, not a dependency decision.
• Use cases where the pattern fits: form/request validation with custom domain rules, ETL boundary checks, config-file validation at boot, and multi-tenant rule sets where different tenants get different filter stacks.

When to Consider This Package

Consider it when:

• You are explicitly evaluating the PSX ecosystem (apioo/PSX framework components) and want consistency across that stack, including its filter/validation conventions.
• You need a standalone, framework-agnostic filter pipeline and are comfortable that Laravel integration would be hand-rolled (service provider, facade, exception mapping) rather than provided.
• Your team values small, single-purpose libraries over batteries-included validators, and can absorb the maintenance ownership of a low-traffic dependency.
• You are doing a design spike on rule composition and want a readable reference implementation under a permissive license (Apache-2.0 — friendly for commercial use, modification, and internal forks).

Look elsewhere when:

• You need production-grade reliability signals: 1 star and 0 dependents means no community backstop, no ecosystem of answers, and effectively no external bug-finding. Any defect you hit, you fix.
• You want first-class Laravel ergonomics — FormRequest, Validator::make, Rule objects, localization, and testing helpers. Laravel's native validator already covers this and is maintained with the framework.
• You need security-reviewed input handling in a regulated or high-exposure surface. Unvetted validation code is a poor place to accept risk.
• You need JSON Schema conformance specifically; dedicated schema validators are a better fit.
• You need maintenance SLAs, long-term support, or vendor accountability — none are available here.

Practical comparison set for the buy/borrow decision: Laravel's built-in Validator, Symfony Validator, Respect/Validation, and a JSON Schema implementation. psx/validate should be benchmarked against these and will likely lose on maintenance and integration while possibly winning on rule-composition ergonomics.

How to Pitch It (Stakeholders)

To executives (one paragraph): We reviewed psx/validate, a small open-source PHP library for validating data through composable filters. It is a good illustration of a pattern we may want — reusable, declarative validation rules that keep data-quality logic out of controllers and services — but it is not a dependency we should adopt. It has negligible community adoption, no downstream users, and no support commitments, which means we would own all maintenance and every bug. The recommendation is to use it as a design reference only, and to make the actual build-vs-buy call among better-supported options (the framework's built-in validator or a mainstream rules library). Licensing is permissive (Apache-2.0), so referencing or forking for internal study carries no legal friction.

To engineering (short): Worth a 30-minute spike if we are designing a rule-composition layer for API payload or ingestion validation — read it for the filter-chain model, not for the code quality bar. Do not add it to composer.json for anything customer-facing. If we proceed with an in-house rule engine, borrow the composition idea, keep our own rules typed and unit-tested, and make sure error message mapping and localization are handled at our layer.

Decision requested: Approve a time-boxed spike using this as reference material, with adoption explicitly out of scope; the resulting recommendation should name a maintained validator as the implementation path.