Tld Database Laravel Package

Product Decisions This Supports

• Domain input validation — deciding whether a signup, email, URL, or webhook field should be validated by a Public Suffix List-aware check rather than a naive regex (\.([a-z]{2,})$), which rejects example.co.uk or accepts foo.invalidtld.
• Registrable-domain (eTLD+1) extraction — the primitive behind multi-tenant architecture decisions: scoping cookies to tenant.example.com vs. the registrable domain, deriving per-customer rate-limit and cache keys, segmenting analytics by customer, and routing wildcard subdomains. This is where the package's value is concentrated.
• Security posture decisions — cookie-scoping and host-allowlist logic that must not treat co.uk or github.io as a registrable domain; relevant to session-fixation, open-redirect, and SSRF review findings.
• Build vs. buy vs. inherit — the package represents the "buy a tiny dependency" option for PSL handling. Because it is archived and deprecated (last release 2019-08, 0 dependents), the decision it actually informs is whether to adopt a library at all, vendor a PSL snapshot with a refresh job, or absorb domain parsing into a platform utility.
• Technical-debt triage — if it appears in an existing composer.json, this assessment supports a deprioritize-vs-schedule-migration call: the risk is stale suffix data (all gTLDs and IDN changes since 2019 are missing), not exploitability of the code itself.
• Roadmap framing — whether "domain handling" becomes a shared platform capability (one owned parser + data-refresh pipeline) or stays a per-feature regex, which historically is how inconsistent validation bugs get shipped.

When to Consider This Package

Consider it only in these narrow cases:

• A legacy Laravel/PHP application already depends on it and you need a short-term, low-risk reason to leave it in place while you budget the replacement.
• You need a frozen, offline snapshot of the 2019 PSL for a hermetic/air-gapped environment where no data refresh is possible and correctness on post-2019 TLDs is not required.
• You want to read its source as a reference implementation of PSL matching semantics before building or selecting a successor — not to install it.

Look elsewhere (or build) if any of the following hold:

• You are starting anything new. Archived + deprecated + zero dependents + a 2019 data freeze is a hard no for a new composer require.
• Correctness matters for security (cookie scope, SSRF/host allowlists) or revenue (tenant provisioning, billing per domain) — stale suffix data produces false accepts and false rejects that are hard to detect in QA.
• You need PHP 8+ / Laravel 10+ support, composer audit cleanliness, or an actively patched data feed.
• You need IDN/Unicode (U-label vs A-label) handling and current ICANN section rules.

Alternatives to evaluate in a spike: a maintained PSL parser such as pdp/pdp (PHP Domain Parser), the same author's layer-shifter/tld-extract for extraction-only use, or vendoring the official PSL file with a scheduled refresh job plus a thin matcher (~200 LOC) — often the most durable option because the data and the code age independently. Validate whichever you pick against a fixture set of co.uk, github.io, s3.amazonaws.com, punycode hosts, and a post-2019 gTLD.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated layershifter/tld-database as a way to get correct domain handling — the logic behind tenant subdomains, cookie scoping, and validating customer-supplied URLs. Recommendation: do not adopt. The package is explicitly deprecated, the repository is archived, it has zero dependents, and its Public Suffix List data has been frozen since August 2019, meaning it will misclassify every top-level domain added or changed in the last several years. The cost of adoption looks like zero (Apache-2.0, small footprint) but the real cost is a silent correctness and security gap in exactly the places where domains matter — multi-tenant isolation and host allowlists. If it already exists in our codebase, treat it as tracked technical debt with a scoped migration, not as a building block for new work.

To engineering (summary): Small, clean, Apache-2.0 abstraction over the PSL with a Laravel-friendly surface — but it is a dead branch. Do not add it to new services. Where it exists, replace it with either pdp/pdp (maintained, current data) or an in-house matcher over a vendored PSL file with a scheduled refresh, and pin the decision with a conformance fixture suite covering multi-label suffixes, private-section domains, and IDNs. Budget roughly a day for the swap plus test coverage; the risk being retired is stale-data misclassification in cookie scoping and tenant routing, not a CVE.