somnambulist/validation
Somnambulist Validation provides a Laravel-friendly validation toolkit for PHP, helping you define reusable rules and validate requests, forms, and application data through a clean, extensible API.
Architecture fit. somnambulist/validation is a standalone PHP validation library, a rewrite of rakit/validation, with an API explicitly modeled on Laravel's validator. That positions it as a candidate only where a Laravel-style validation API is wanted outside the Laravel framework. If the target service is Laravel, the framework's built-in Validator already provides this contract with first-party support and should be preferred; introducing this package would add a dependency without capability gain. If the target is a Symfony, Slim, or bespoke PHP service, the package may fit as an isolated, framework-agnostic validation layer — assuming it is PSR-friendly and does not drag in framework internals.
Integration feasibility. Composer-installable and MIT-licensed, so legal and packaging friction is low. The real feasibility question is API surface: the package must support the rule set we actually need (nested/array validation, custom rules, conditional rules, error message customization, i18n) and must be usable without Laravel's container. Because it is a rewrite of rakit/validation, parity with that library's documented behavior — and any deliberate divergences — needs to be verified against our existing rule usage before we treat it as a drop-in.
Technical risk. The dominant risk is project maturity, not code complexity. 64 stars, 0 dependents, and a low opportunity score (30.39) indicate a package with essentially no production adoption signal. Validation is a well-understood domain, so the functional risk is modest, but the supply-chain risk is meaningful: a single-maintainer library sitting directly in the request path of every service that uses it. An unmaintained or compromised validation layer can silently accept malformed input, which is a security-relevant failure mode. We should also confirm PHP version support, test coverage/CI status, static analysis, and release cadence.
Key questions.
rakit/validation does this rewrite address, and are those gaps relevant to us?respect/validation, Symfony Validator, or Laravel's illuminate/validation used standalone) that covers the same need with better support?Stack fit. Adopt only for non-Laravel PHP services where a Laravel-flavored rule DSL is a genuine productivity win for the team. For Laravel services, standardize on the framework validator and do not introduce this package. For Symfony-based services, evaluate Symfony Validator first; it is first-party, widely adopted, and better supported. This package should be treated as a niche option, not a default.
Migration path. If we are replacing rakit/validation, the rewrite lineage suggests a relatively low-friction port, but the migration must be validated rule-by-rule, not assumed. Build a compatibility test suite from our current rule definitions and assert identical accept/reject behavior and error message shapes before cutover. If we are replacing ad-hoc validation, wrap the library behind a thin internal ValidatorInterface so the package is not referenced directly across the codebase — this preserves the option to swap implementations later with minimal blast radius.
Compatibility. Pin the package version explicitly, verify PHP version alignment across all target services, and audit transitive dependencies for license and CVE exposure. Confirm behavior under our supported locales if error messages are user-facing. Check that the package does not assume a global container or Laravel helpers.
Sequencing.
illuminate/validation on adoption, support, and API fit.Maintenance. Low activity and 0 dependents mean we should expect to own this dependency, not consume it. Budget for internal stewardship: tracking upstream, applying patches, and potentially forking if the maintainer goes inactive. That ongoing cost is the main hidden expense and should be weighed against the library's convenience.
Support. No commercial support and a small community. Incident response depends on the maintainer's availability, which is a single point of failure. Internal runbooks should document the validation rules in use and the fallback behavior if the package must be removed under time pressure.
Scaling. Validation is CPU-cheap relative to I/O; this package is unlikely to be a throughput bottleneck. The scaling concern is organizational: every service that adopts it inherits the same maintenance obligation, and divergent local forks will accumulate unless we enforce a single pinned version and adapter contract.
Failure modes. The most consequential failures are silent: a rule that no longer matches intended semantics after an upgrade, locale-dependent message regressions, or malformed input accepted because a custom rule was misconfigured. Less severe are message-format drift and missing-rule errors at runtime. Mitigations are behavioral regression tests around the adapter, fail-closed validation defaults, and a version pin with deliberate upgrade reviews.
Ramp-up. The Laravel-inspired API is the package's main strength: PHP developers familiar with Laravel validation will be productive quickly, and the rule DSL is readable in code review. That reduces onboarding cost. The offsetting cost is that engineers must also learn the package's divergences from Laravel and the internal adapter conventions, and must understand that this is a low-adoption dependency requiring extra care during upgrades.
Recommendation. Treat somnambulist/validation as a conditional fit: reasonable for non-Laravel PHP services that want a Laravel-style DSL and are willing to own the dependency, but not a default choice given 0 dependents and thin adoption. Run the spike and compare against Symfony Validator and standalone illuminate/validation before committing; if the team cannot commit to internal stewardship, standardize elsewhere.
How can I help you explore Laravel packages today?