Laravel Validator Pizza Laravel Package

Technical Evaluation

Architecture fit. Unchanged in kind by 1.1.0, which is a version-constraint bump rather than a feature release: it widens illuminate/* to admit Laravel 7 and, from the note provided, adds no rules. The package remains a service provider registering extra rules into the Validator facade — no persistence, no queue, no events, no configuration surface worth designing around. It slots into the framework's validation layer without touching request handling, middleware, or container bindings, so composition is not the question. The question is whether a leaf utility package whose rule set is now largely native to Laravel justifies a third-party dependency at all. uuid, ulid, password, current_password, prohibited, exclude, decimal, multiple_of and the comparison rules are core. Marginal architectural value: still near zero.

Integration feasibility. Low friction on a legacy stack, blocked on a current one — and 1.1.0 does not move that boundary in any way that matters. The ceiling moves from Laravel 6.x to 7.x, but Laravel 7 reached end of life in March 2021, so the release raises support to a framework generation that is itself out of support. Against our baseline (Laravel 10/11/12, PHP 8.2+) install still fails at dependency resolution time — cheap and loud — not at runtime. The pattern matters more than the version number: a single compatibility commit followed by archival and a rename is the signature of a project being closed out, not resuscitated. The Archived: yes flag and the "has been renamed" description still mean the canonical install target has moved; the repository we are evaluating is a tombstone with one last coat of paint.

Technical risk. Elevated and asymmetric, unchanged. Runtime risk is genuinely small — validation rules are pure predicates over scalars. Supply-chain and lifecycle risk is not: archived means no security disclosure path, no issue tracker, no patch cadence, and no maintainer to answer "does this rule behave as I think under Laravel 12?" Zero dependents means no community canary. The 1.1.0 bump introduces a specific, small new hazard: it validates the idea that the package is alive, which makes it marginally more likely that an engineer pins it in a legacy service and treats it as maintained. The rename still splits the SBOM from the mental model, with teams potentially pinning the abandoned name believing they are on the successor.

Key questions. What is the successor package, and is it maintained and constrained against our Laravel/PHP baseline? Is 1.1.0 a one-line composer.json widening or does it carry PHP 8 signature work — i.e. did anything in the source actually change? Does any service currently pin this package, and at which constraint? Which rules in the provider are still not covered by core for our target Laravel version? Is anything dependent on the old package name in lockfiles today? And is the business requirement behind the validation (a specific national ID or phone format) owned by a rules library at all, or should it live in domain code?

Integration Approach

Stack fit. Laravel-only, and now only the older half of it with a slightly higher ceiling. Laravel 10/11+ on PHP 8.2+ remains non-installable — plan around it, not through it. If a legacy Laravel 7 service is still in maintenance, 1.1.0 is the version to pin if we must, but the framing stays "freeze and isolate," never "adopt." A Laravel 7 bump does not justify reopening an already-closed decision.

Migration path. Three options, in descending order of preference, unchanged by this release. First, substitute the successor identified by the rename — verify its release history, constraint, and issue activity; the fact that the predecessor shipped one last compatibility commit does not imply the successor is alive. Second, port the rules we actually use into app/Support/Validation/Rules/ against Illuminate\Contracts\Validation\Rule / InvokableRule, test them, and delete the dependency. A day of work that converts an unmaintained dependency into first-party code. Third, fork and pin only if the successor is also dead and the rule set is large enough that porting is uneconomic — accepting a permanent, owned maintenance line.

Compatibility. The mechanical gaps are the usual ones: PHP 7 signatures to PHP 8 typed properties and return types, the Rule contract's move to closure-based $fail callbacks, Laravel 9's InvokableRule, and message plumbing that can surface raw translation keys if lang/ files are unpublished or un-namespaced. The 1.1.0 constraint bump tells us nothing about whether any of that was addressed. Rule names are the subtler surface: a ported rule colliding with a native rule of the same name means registration order decides behavior — exactly the ambiguity that produces silent validation bypasses.

Sequencing. (1) Inventory: grep composer.json, lockfiles, and FormRequests for the package name and any custom rule names, and record the pinned constraint (this is where 1.1.0 will show up if anyone upgraded on the quiet). (2) Gap analysis against native rules for our target Laravel version; expect this to collapse most of the list. (3) Decide substitute-versus-port in a short ADR. (4) Implement behind feature-flagged FormRequest changes so behavior can be diffed against production traffic before cutover. (5) Remove the dependency and any replace/fork scaffolding in the same release. Do not sequence this alongside a Laravel major upgrade.

Operational Impact

Maintenance. Archived still means the maintenance burden transfers to us the moment we install it. The 1.1.0 release does not change that arithmetic: one compatibility commit is a pulse, not a cadence, and there is no second data point suggesting a maintenance commitment. The absolute cost stays small — validation rules rarely change — but it is unowned cost: no upstream to absorb a CVE, no changelog to read before an upgrade, no one to escalate to. With a score of 0.0925 and zero dependents, the disposition is "do not add," and for anything already present, "remove on the next maintenance window."

Support. No support channel. The repository is archived, so issues and PRs are closed by construction; the 1.1.0 note is the last thing we will read from upstream. Internal engineers are the sole escalation path, and the answer will come from reading source, not documentation. Budget for that in ramp-up rather than pricing it at zero.

Scaling. Non-issue. These are CPU-bound scalar predicates inside the framework's existing validation pass — no I/O, no connection pool, no cache, no queue. The package cannot become a throughput bottleneck or a horizontal-scaling constraint. The scaling risk is organizational: the number of engineers who understand why each rule exists and what it should reject decays over time.

Failure modes. The dominant failure is installation failure at a framework upgrade — loud, early, cheap. The dangerous ones are quiet: a rule silently dropping out of registration via auto-discovery or provider ordering so invalid input passes; a name collision with a native rule yielding the wrong predicate under the right key; a missing translation file surfacing validation.custom.foo to end users; and a ported rule losing an edge-case branch during the PHP 8 rewrite and loosening validation with no test noticing. Mitigate all four with direct unit tests against Validator::make — positive, negative, and boundary per rule — committed before the port, not after.

Ramp-up. Trivial for a Laravel-fluent engineer: an hour to read the provider and enumerate rules, a day to port and test a realistic set. The real cost is decision overhead — confirming the successor's status, agreeing substitute-versus-port, getting the ADR reviewed — two days of conversation for a package whose entire value is a dozen small string and number checks. The 1.1.0 release does not earn a re-litigation of that decision; note it as a factual correction to the compatibility ceiling (Laravel 7, itself EOL since 2021), confirm nobody quietly pinned it, and hold the recommendation: evaluate the successor once, otherwise port and delete.