- What does romanzipp/laravel-validator-pizza actually do?
- It is a small Laravel package that wraps the laravel.pizza disposable email API and registers a validation rule through a service provider, so you can reject throwaway email addresses inside the standard Validator facade. There is no persistence, no queue, no events and no meaningful configuration surface. It sits entirely inside Laravel's validation layer and does not touch request handling, middleware or container bindings.
- How do I install romanzipp/laravel-validator-pizza with Composer?
- Run composer require romanzipp/laravel-validator-pizza and let Laravel package auto-discovery register the service provider. The catch is dependency resolution: version 1.1.0 only widens the illuminate/* constraint as far as Laravel 7, so on a Laravel 10, 11 or 12 application the install fails immediately at Composer resolution time rather than at runtime. That failure is cheap and loud, but it means the package is not installable on a current stack.
- Does this package support Laravel 10, 11 or 12?
- No. The most recent release, 1.1.0, is a version-constraint bump that admits Laravel 7 and does not add rules or change behaviour. Laravel 7 itself reached end of life in March 2021, so the package's ceiling is a framework generation that is already out of support. On a Laravel 10, 11 or 12 baseline with PHP 8.2 or newer, installation fails at dependency resolution.
- Is romanzipp/laravel-validator-pizza still maintained?
- No. The repository is archived, has been renamed, and its description points to a new canonical target, so the package we are evaluating is effectively a tombstone with one last compatibility commit. Archival means no issue tracker, no patch cadence, no security disclosure path and no maintainer to answer questions about how a rule behaves on modern Laravel. The 1.1.0 bump should not be read as a sign of life.
- What Laravel and PHP versions does version 1.1.0 support?
- Version 1.1.0 widens the illuminate/* constraint to admit Laravel 7 and remains a Laravel-only package, so it does not run on Laravel 10, 11 or 12. The release is a constraint change rather than a feature release and, per the available notes, adds no new rules. Treat the ceiling as Laravel 7, which is end of life.
- Does the rule make an external HTTP call, and what are the production concerns?
- Yes. The package validates disposable addresses by querying the laravel.pizza API, so each validation is a network round trip that adds latency to requests that trigger it. In production you should think about API availability, rate limits, timeouts and whether the check fails open or closed when the service is unreachable. Caching results per domain or per address is usually necessary to keep validation cheap.
- How should I test code that relies on this validation rule?
- Never let tests hit the laravel.pizza API. Fake the HTTP layer with Laravel's Http::fake so you can assert both the disposable and non-disposable paths deterministically. If you port the logic into your own rule class, extract the API client behind a contract and bind a fake implementation in the container.
- What are the alternatives to romanzipp/laravel-validator-pizza?
- First, check what Laravel core already covers, since many validation needs are native and require no dependency at all. For the disposable-email check specifically, write a small class implementing Illuminate\Contracts\Validation\Rule or InvokableRule in app/Support/Validation/Rules, call the API through Laravel's HTTP client, and test it yourself. Verify the successor package named in the rename before adopting it, because one last compatibility commit on the predecessor does not prove the successor is alive.
- The package has been renamed, so which name should I install?
- The archived repository points to a successor name, and the two packages should not be treated as interchangeable by default. Before pinning anything, check the successor's release history, its Laravel and PHP constraints, and whether its issue tracker shows activity. Teams that pin the old name assuming they are on the maintained successor will end up with a split between their SBOM and their mental model of the dependency.
- Should I use this package in a new project or keep it in a legacy Laravel 7 service?
- For new work, no. It is archived, has zero dependents, and adds an unmaintained third-party dependency around a single external API call that is easy to own in domain code. If a legacy Laravel 7 service still pins it, keep the constraint frozen, isolate the usage and plan a migration to a native rule or the verified successor rather than reopening the adoption decision.