Validation Laravel Package

Product Decisions This Supports

• Build vs. buy for input validation. Rakit remains a near-zero-cost buy: MIT-licensed, Composer-installable, no framework dependencies. It removes the "we'd have to write our own rule engine" argument that stalls validation work in non-Laravel codebases. v1.0.0 strengthens the buy case by adding a stability signal (1.0 API commitment) plus typehints, PHPDoc, and PHP_CodeSniffer enforcement — meaningfully lower integration friction for teams running static analysis.
• Standardizing validation semantics across a mixed estate. If you run a Laravel app alongside a legacy PHP service, a WordPress plugin, or a distributed SDK, Rakit lets both sides use the same Validator::make() rules and the same error vocabulary. That's a shared contract, not just a library choice.
• Shipping SDKs and embeddable libraries. You cannot force downstream consumers onto Laravel. A zero-framework-dependency validator lets you publish a package with real input validation instead of hand-rolled if (!isset(...)) checks.
• Unblocking legacy modernization. Teams that want Laravel-quality validation but are years away from a framework migration can adopt this tactically without committing to a platform roadmap. The PHP floor moving to 7.0 is now helpful here — it aligns with the minimum most legacy estates have already reached.
• Nested/payload-heavy product surfaces. Dot-notation and wildcard rules support complex JSON bodies, multi-row imports, and config uploads without bespoke validation code — relevant for API products and data-ingestion features.
• File and media upload features (newly material). v1.0.0 adds a mimes rule reading from $_FILES, extends uploaded_file to multiple files, and makes min/max/between validate uploaded file size. That turns a previously hand-rolled area — avatar/document/CSV upload validation — into declarative rules. Relevant for admin tooling, import pipelines, and any product surface accepting user-supplied files.
• Error-message UX and localization roadmap. The new TranslationsTrait and Rule::setParameterText / getParametersTexts let us swap translations wholesale and render human-readable field and parameter names in messages ("The Billing email field must be one of Card, Invoice") instead of leaking rule internals. Dynamic in/not_in/uploaded_file messages do this out of the box. This is customer-facing quality, not just plumbing, and it de-risks international expansion on small teams.
• Domain-specific rules as product logic. Custom rules and inline closures let product-defined constraints (plan tiers, regional restrictions, ID formats) live as named, testable rules rather than scattered conditionals.
• Fork/vendor as a strategic option. Still a legitimate posture at this size and license — but now a contingency rather than the expected default (see risk note below).

When to Consider This Package

Adopt when:

• The project is PHP but not Laravel, and you need expressive rule-based validation.
• Your team already knows Laravel's validator — reuse of familiar rules and error messages cuts onboarding and code review friction.
• You're building a library or SDK and must avoid pulling illuminate/* into someone else's dependency tree.
• You have legacy code where validation quality is a real defect source, but a framework migration is not funded.
• You need nested array validation via dot notation/wildcards, custom closures, file-upload and MIME/size validation, or localized messages with named parameters — and nothing more.
• Your runtime is PHP 7.0+ (now a hard floor; verify 8.x behavior yourself — the changelog confirms 7.0, not 8.x).
• You're comfortable pinning to ^1.0 and vendoring if maintenance lapses again.

Look elsewhere when:

• The system is regulated or has dependency-support obligations (SBOM requirements, CVE SLAs, vendor support contracts). v1.0.0 is a strong signal but is not a support commitment — there is still no published security policy, LTS branch, or response SLA.
• You require guaranteed forward compatibility. This release is a major-version bump with breaking changes: PHP minimum 5.5 → 7.0, Rule::check() must now return bool, and ErrorBag::firstOfAll() returns an associative array instead of an indexed one. Anyone on 0.x must plan a migration, not a patch bump.
• You are already on Laravel — use the framework's validator; do not run two validation layers.
• You need schema-first or metadata-rich validation (JSON Schema, attribute-based constraints, rich constraint introspection) — Symfony Validator is the better-maintained fit.
• You need PSR-7/PSR-15 middleware integration, or validation in a high-throughput hot path. Note the new file rules are $_FILES-coupled, so they don't help streamed/PSR-7 uploads.
• The team is unwilling to own a fork even as a contingency.

How to Pitch It (Stakeholders)

What it is: A small, MIT-licensed PHP library that gives any PHP codebase the same Validator::make() API Laravel developers already use — without adopting Laravel. v1.0.0 shipped this cycle: the first release since 2018.

Why it matters: Input validation is where a large share of data-integrity bugs and injection-adjacent defects originate. Standardizing on one expressive, widely understood rule syntax replaces ad-hoc, inconsistent checks with reviewed, testable rules — and lets one team's validation knowledge transfer to every codebase we own. This release also closes a real capability gap: native file-upload validation (MIME type, multi-file, file size) and customer-facing message quality (named parameters, swappable translations), which were previously hand-rolled per project.

Cost: Low. One Composer dependency, no framework lock-in, no infrastructure change, no licensing cost. It can be vendored into our repo if needed.

Risk: Materially reduced, not eliminated. The headline concern in the prior assessment — an eight-year release gap — is retired: there is now an active maintainer shipping a considered 1.0 with code-style enforcement, typehints, and PHPDoc. What remains is no formal support commitment (no LTS, no CVE SLA, no security policy), and this is a breaking release: PHP 7.0 floor, Rule::check() must return bool, and ErrorBag::firstOfAll() changed shape — the last one is product-visible if we render error payloads straight from that method. Mitigations: (a) replace the compatibility spike with a migration spike covering the three breaking changes plus a PHP 8.x check, (b) pin to ^1.0 and hold the vendor/fork decision as a documented contingency, (c) keep the Symfony Validator fallback documented for regulated surfaces.

Recommendation: Adopt for non-critical, framework-less surfaces — internal tools, distributed SDKs, legacy modules, upload-handling features — after the migration spike. Do not adopt for systems with dependency-support obligations. Treat the package primarily as a pattern for standardizing validation semantics, with the library as its cheapest implementation today — and now, a visibly maintained one.

Decision requested: Approve the migration spike (breaking-change inventory + PHP 8.x verification), and record our posture — buy with ^1.0 pinning, fork only if maintenance lapses again — so engineering isn't blocked mid-sprint.