arubacao/tld-checker
Validate top-level domains and email addresses in Laravel. Check whether a TLD exists, support generic and country-code domains, and reject emails with invalid or misspelled TLDs using a bundled, updatable TLD list—no external API calls required.
Baseline note: No prior assessment exists; 1.2.70 is the baseline for all future comparison. This evaluation is derived from the release delta and package metadata, not from a hands-on spike — treat the "key questions" as verification items to close before adoption.
Architecture fit. arubacao/tld-checker is a narrow, single-purpose validation utility: it answers "is this TLD a real, recognized TLD?" for email/URL/domain inputs. That makes it a low-coupling dependency — it sits behind Laravel's validation layer and does not touch persistence, queueing, or HTTP. Architecturally it is a leaf dependency, which is the best kind: it can be adopted or removed without refactoring domain code, provided the team wraps it behind its own validation rule rather than invoking the package rule directly in dozens of FormRequests.
The one architectural consideration that matters is data provenance. A TLD validator is only as good as its TLD list, so the real architectural question is whether the list is bundled static data (deterministic, testable, but ages) or fetched at runtime (fresh, but introduces a network dependency into a synchronous validation path). That distinction drives most of the risk below.
Integration feasibility. Low effort. The release is a patch bump (1.2.70) adding PHP 8.0 support, which is a compatibility unlock rather than a functional change. Integration is a Composer require plus registration of a service provider and, typically, a single validation rule string. Expected effort is well under a day for a first working integration including tests; the residual work is policy (when do we refresh TLD data?) rather than engineering.
Technical risk. The headline risk is not the code — it is the signal in the release note. Adding PHP 8.0 support in a 1.2.x patch means the package's supported-runtime floor has been trailing the ecosystem: PHP 8.0 reached end-of-life in November 2023. A release that lands 8.0 support now tells us the maintainer is catching up on runtimes that are already unsupported, which raises fair questions about how current the supported-Laravel matrix and the TLD dataset are. Secondary risks:
Key questions.
false, or pass-through?Stack fit. Good fit for a Laravel application already using the Validator facade and FormRequest-based validation. It composes with email, url, and regex rules rather than replacing them — typical usage is email + tld for a stricter email check, or url + tld for link fields. It is a poor fit if the actual requirement is "does this mailbox exist" or "is this domain deliverable" — that needs DNS/MX and SMTP verification, which is out of scope here. Confirm the requirement is syntactic TLD validity before adopting.
Migration path. Greenfield adoption is trivial. If replacing hand-rolled TLD regexes or a hardcoded array in application code, the migration is: introduce the package rule, wrap it in an application-owned rule class (e.g. App\Rules\ValidTld) that delegates to the package, then swap call sites to the wrapper. The wrapper is the whole point — it makes a future package swap or a fork a one-file change, and it gives a single place to add logging when validation fails suspiciously.
Compatibility. Pin explicitly in composer.json and verify the constraint resolves against the app's PHP and Laravel versions before merging; the 8.0-only framing in the release note makes it unclear whether the constraint is a floor or a ceiling. Run the app's existing validation test suite against the new dependency, and add fixture cases for: a classic gTLD (.com), a newer gTLD, a ccTLD, an IDN TLD, a deliberately fake TLD (must fail), and a bare hostname with no TLD (must fail). Those six cases are the minimum regression net.
Sequencing.
Maintenance. Low code surface, but non-zero ongoing obligation: the dataset needs periodic refresh, and the package needs routine Composer updates for PHP/Laravel compatibility. Budget a small recurring task (roughly quarterly) rather than treating this as install-and-forget. The 1.2.70 note is a reminder that the maintainer's runtime support can lag; a scheduled dependency-review job in CI is the cheapest mitigation.
Support. Internal support burden is minimal — failures surface as ordinary validation errors. The support risk is diagnostic, not operational: when a legitimate customer is rejected, the error message ("invalid TLD") does not tell anyone that the dataset is stale. Mitigate by having the wrapper log the rejected TLD value so a support ticket can be triaged in minutes.
Scaling. Effectively free. TLD validation is an in-memory lookup (array or compiled regex) per input; it adds microseconds and no I/O, assuming the dataset is bundled. This scales linearly with request volume and imposes no database, cache, or network pressure. The caveat: if the implementation performs a network fetch or reads a remote list on the validation path, that assumption breaks — treat confirmation of the bundled-data design as a hard gate, not a nice-to-have.
Failure modes.
email/DNS layer usually catches it downstream.Ramp-up. Near zero for any PHP developer familiar with Laravel validation. Allow roughly half an hour for a mid-level engineer to read the README and ship the wrapper plus tests. The genuinely non-obvious knowledge is operational rather than technical: where the TLD list comes from, when it was last refreshed, and who owns the refresh reminder. Capture that in the integration PR description so it survives staff turnover. The net assessment is adopt with a wrapper and a refresh cadence — the package is small, cheap, and low-risk, but it should be treated as periodically-perishable configuration rather than as static library code.
How can I help you explore Laravel packages today?