Laravel Validator Pizza Laravel Package

Getting Started

This package is archived and renamed. Before anything else, read the README banner and the Packagist page — the repository description literally points at the successor. The fastest way to discover the new name is to attempt an install in a scratch project: Composer prints an "abandoned, use X instead" notice that names the replacement package directly.

1. Decide whether you're adopting or excavating. For new code, install the successor package, not romanzipp/laravel-validator-pizza. The archived version now spans Laravel ~5.5–7.x (1.1.0 added Laravel 7 support), still has zero dependents, and has no community pressure keeping it compatible beyond that.
2. For legacy apps pinned to an older Laravel (5.5 through 7.x): composer require romanzipp/laravel-validator-pizza:^1.1. If you're on Laravel 7, 1.1.0 is the release you want — earlier tags predate that support. Package discovery registers the service provider automatically; there is no manual config/app.php entry needed on 5.5+.
3. Look here first, in order: the README rule table (the public contract), then src/ for the service provider and rule classes, then tests/ — for a small archived package the test suite is the documentation and shows exactly which inputs pass and fail.
4. First use case: find a hand-rolled regex or in: validation in an existing FormRequest and replace it with the package rule. Write a data-provider test with valid and invalid samples against the rule before wiring it into the request, so you learn its real behaviour rather than its advertised behaviour.

Implementation Patterns

String-rule usage in FormRequests is the intended path — drop the rule name into rules() alongside built-in rules. Compose with nullable, sometimes, and bail so you don't run expensive checks after a cheap one already failed.

Rule objects suit conditional or array-driven validation, where you need to pass constructor arguments (country codes, strictness flags). Instantiate inline in rules() or resolve from the container if the rule needs config.

Wrap it, don't scatter it. This is the decisive pattern for an archived dependency:

// app/Rules/ItalianVat.php
final class ItalianVat implements ValidationRule
{
    public function validate(string $attribute, mixed $value, Closure $fail): void
    {
        $v = Validator::make(['v' => $value], ['v' => ['required', new PackageVatRule()]]);
        if ($v->fails()) {
            $fail($v->errors()->first('v'));
        }
    }
}

Every request then references App\Rules\ItalianVat. When you swap to the renamed package — or vendor the logic — you edit one file instead of every FormRequest.

Message customisation happens at two levels: per-field overrides in the request's messages() array, or publishing translation files and editing the vendor language lines. Publish first, then edit — never edit inside vendor/.

Migration path for the rename: if the successor ships a new namespace, add a thin alias class under the old name during the transition and delete it once all references are updated. Keep a single commit that flips the namespace so the diff is reviewable.

Upgrading to 1.1.0: the release notes only claim Laravel 7 support, so treat it as a compatibility widening rather than a feature release. Bump the constraint, run composer update romanzipp/laravel-validator-pizza, clear the config cache, and re-run your rule-level tests. There's no migration guide because there's nothing to migrate — but confirm the transitive illuminate/* constraints actually resolved to your app's framework version rather than silently downgrading it.

Gotchas and Tips

• The abandoned notice is the documentation. Composer's warning names the replacement package; treat it as authoritative over any blog post — including this one, if the rename target changes again.
• 1.1.0 does not un-archive the package. A Laravel 7 support bump is the last maintenance gesture of a dead project, not a revival. Don't read it as a signal that Laravel 8/9/10 support is coming.
• Contract drift with modern Laravel. The package likely implements Illuminate\Contracts\Validation\Rule. That still functions on Laravel 7–11 but is soft-deprecated in favour of ValidationRule; on Laravel 9+ you may see deprecation noise or mismatched validate() signatures if the package extends anything internal. Laravel 7 is the newest framework it explicitly targets, so anything above that is untested territory.
• Version constraint traps. Pinning ^1.0 won't pull 1.1.0's Laravel 7 support if your lock file predates it; pin ^1.1 explicitly or you'll debug a phantom incompatibility. Conversely, if you need Laravel 6, check whether 1.1.0 dropped any constraint before bumping.
• Silent non-registration. If a rule string produces "validation rule does not exist" or passes everything, the provider isn't loaded — package discovery may have been disabled (composer install --no-scripts) or the config cache is stale. Run php artisan package:discover and php artisan config:clear.
• Locale assumptions. Check the resources/lang / lang directory before shipping; messages may exist only in one language, and Italian-source rules sometimes have Italian-only text that surfaces in production error responses.
• Edge-case semantics. VAT/tax-code style rules usually have strictness toggles (checksum-only vs. full pattern, leading zeros, whitespace). Read the tests for the exact behaviour rather than assuming ISO compliance.
• Vendor it. The MIT license means you can copy the rule classes into app/Rules, drop the dependency, and own the maintenance. For a 19-star archived package with zero dependents, this is usually the lowest-risk outcome — you keep the logic and lose the supply-chain question. The 1.1.0 bump doesn't change that calculus; it just gives you a slightly later starting point to copy from.
• Pin and track. If you keep the dependency, pin an exact version in composer.json and add a tech-debt note with the rename target, so the next developer doesn't rediscover the archive status the hard way.