Tld Extract Laravel Package

Product Decisions This Supports

• Build vs. buy (and here, "buy vs. borrow"): This package answers a narrow, well-defined question — given a hostname or URL, what is the registrable domain, the public suffix, and the subdomain? That capability underpins a surprising number of product features, so the decision worth making is not "should we install this" but "which PSL-backed parser do we standardize on." TLDExtract is a useful specification of the requirement, not the implementation.
• Multi-tenant and subdomain routing: Any feature where a customer gets acme.yourapp.com needs to reliably separate the tenant label from the base domain — including for multi-part suffixes like acme.co.uk or shop.example.com.au. Getting this wrong means cross-tenant data leakage or broken routing.
• Cookie and session scoping: Deciding whether to set a cookie on .example.com versus app.example.com is a security-relevant decision. Naïve "last two labels" logic silently breaks on co.uk, github.io, and other public suffixes — a class of bug that shows up as session bleed between unrelated tenants.
• Email and domain validation / abuse: Extracting the organizational domain from a signup email enables free-vs-corporate email classification, disposable-domain blocking, per-domain rate limiting, and fraud signal aggregation ("12 trials from one registrable domain").
• Analytics and reporting: Grouping traffic, signups, or revenue by registrable domain rather than raw hostname is what makes a "top customers/domains" report meaningful instead of 400 rows of www. variants.
• Roadmap input: If domain parsing appears in two or more roadmap items (SSO domain capture, custom domains, org-level billing), it graduates from "utility" to "platform primitive" and deserves an owned, tested abstraction rather than ad-hoc regex in three services.

When to Consider This Package

Do not adopt TLDExtract for new work. The README is marked [DEPRECATED], the repository is archived, the last release was February 2019, and it has zero dependents on the recorded index — a strong signal that the ecosystem has moved on. On any modern Laravel stack (PHP 8.x, Composer 2), expect the practical failure modes of an abandoned 2019 library: stale or incompatible version constraints, no service provider or facade for Laravel, no PHP 8 type-safety, and an unpatched dependency surface.

Consider it only as:

• A reference implementation when writing an internal spec or spike for domain parsing — its API shape (suffix, registrable domain, subdomain) is a sensible contract to copy.
• A legacy read: if it already exists in an inherited codebase, treat it as technical debt with a migration ticket, not a component to extend.

Look elsewhere — or build a thin wrapper — when any of the following hold:

• You need a current Public Suffix List. The PSL changes regularly; a parser pinned to a 2019 snapshot will misclassify newer suffixes (new gTLDs, private suffixes like hosted platforms). The PSL update cadence is the single most important selection criterion for this category.
• You are on a supported PHP version and expect security patches.
• You need Laravel integration (config, facade, validation rule, testing helpers) — this library is framework-agnostic by design.
• You need IDN / punycode handling, since internationalized domains are a common source of edge-case bugs.

Recommended evaluation path: shortlist a maintained PSL-backed parser (e.g. jeremykendall/php-domain-parser — verify current maintenance, PHP support, and PSL refresh mechanism before committing) and wrap it behind your own small DomainParser interface. The wrapper is the real product decision: it isolates you from whichever underlying library wins, makes the PSL snapshot strategy explicit, and gives you one place to add caching and tests.

How to Pitch It (Stakeholders)

For executives: We evaluated an open-source domain-parsing library for an upcoming need — correctly identifying a customer's "real" domain across custom domains, SSO email capture, and per-domain abuse limits. The library is deprecated, archived since 2019, and unmaintained, so we are not taking on that dependency. The underlying need is real and recurring, and getting it wrong has security and data-isolation consequences (cookie scoping, tenant separation). Recommendation: spend a small, bounded effort — roughly a day or two of engineering — to wrap a maintained Public Suffix List parser behind our own interface, with a documented process for refreshing the suffix list. This avoids a recurring class of bugs and prevents three teams from each writing their own regex.

For engineering: This package is a well-shaped API on a dead branch. We're adopting the contract — parse(host) → {suffix, registrableDomain, subdomain} — not the code. Standardize on a maintained PSL-backed parser, wrap it in a single internal service with caching, pin and schedule PSL snapshot updates (treat stale suffix data as a monitored defect, not a footnote), and cover the known-nasty cases in tests: co.uk, github.io, multi-level private suffixes, IDN/punycode, trailing dots, ports, and bare IPs. If TLDExtract already exists anywhere in our codebase, file it as debt with a migration path rather than patching it in place.