Tld Support Laravel Package

Product Decisions This Supports

• Registrable-domain ("eTLD+1") logic as a product primitive. This package is thin Laravel glue over TLDExtract/TLDDatabase, exposing Public Suffix List parsing as a service/facade. Any feature that must answer "what site is this really?" depends on it:
  • Cookie & session scoping — setting cookies on example.co.uk rather than co.uk (a common, serious bug class).
  • Multi-tenant / subdomain routing — separating acme.app.com from app.com for tenant resolution and wildcard SSL coverage.
  • Analytics & reporting — rolling subdomains up to a registrable domain so www., blog., shop. don't fragment dashboards.
  • Trust & safety — phishing/lookalike detection, blocklist matching, rate limiting per registrable domain rather than per hostname.
  • Email & signup validation — validating that an address's domain has a real public suffix; blocking disposable/typo domains.
• Build vs. buy vs. wrap. The real decision isn't "should we use this?" — it's "do we take a dependency on an archived wrapper, spend ~50 lines writing our own service provider around TLDExtract, or adopt a maintained parser?" This package pushes that decision toward "wrap it ourselves" because the value it adds is small and the maintenance signal is bad.
• Roadmap risk input. Because the Public Suffix List changes continuously (new gTLDs, private suffixes like github.io and s3.amazonaws.com), any PSL-backed capability is a recurring maintenance commitment, not a one-time integration. That belongs in roadmap capacity planning, not just a ticket.
• Not a differentiator. This is commodity infrastructure. It should never appear on a roadmap as a feature; it should appear as a risk line item or an engineering-enablement task.

When to Consider This Package

Consider it only if all of the following hold:

• You're on a legacy Laravel 5.x / PHP 7.0-era codebase that already depends on TLDExtract/TLDDatabase directly and you want the facade + config wiring for free.
• The use case is low-stakes and internal (admin tooling, log enrichment, rough analytics bucketing) where a stale suffix list degrades gracefully.
• You're time-boxed and the alternative is "no domain parsing at all this sprint."
• You've verified it installs on your PHP version — the 2016 release predates Laravel package auto-discovery and modern PHP constraints, so expect manual provider registration and possible PHP 8 incompatibility.

Look elsewhere if any of the following are true — and for most teams at least one is:

• You need current PSL data. The last release is June 2016; suffixes introduced since (.app, .dev, .zip, and most private-section entries) will be mis-parsed. In cookie scoping or tenant routing this is a correctness bug, not a cosmetic one.
• You're on PHP 8 / Laravel 9+. Archived since 2016, 38 stars, 0 dependents, no security response path. That's an unowned dependency in your supply chain.
• The logic is security- or billing-adjacent. Anything touching auth boundaries, cookie domains, or per-domain quotas needs a maintained parser with a fresh-list update mechanism.
• You want a maintained alternative. A current PHP Domain Parser implementation (e.g., jeremykendall/php-domain-parser / the pdp lineage) with a bundled or cacheable PSL, or calling TLDExtract directly behind your own small interface, both dominate this package on every axis except "already wired for Laravel."
• You can define a narrow interface. If you isolate DomainParser::parse($host): RegistrableDomain behind your own contract, the vendor choice becomes reversible — which is the strongest argument for not adopting an archived wrapper in the first place.

Read the 0.2 score plainly: low opportunity, zero dependents, archived. This is a candidate for a "do not adopt" line in your dependency policy, not a bake-off entrant.

How to Pitch It (Stakeholders)

For executives (30 seconds): We evaluated a small open-source helper that lets our Laravel app correctly identify the "real" domain behind a hostname — the thing that stops us from setting a cookie on an entire country domain, or from lumping every customer's subdomain into one analytics bucket. The capability matters; this specific package doesn't. It was last released in 2016, is archived, has no downstream users, and its underlying domain data is roughly a decade stale. Recommendation: don't adopt. Fund a one-day engineering task to put the same capability behind our own interface using a maintained library. Cost is trivial; the risk we avoid is a silent correctness bug in cookies, tenants, or per-domain limits.

For engineering (the actual ask):

• What it is: a Laravel service provider + facade over TLDExtract/TLDDatabase. ~No logic of its own. Its entire value is config wiring.
• Why we're passing: archived 2016, 38 stars, 0 dependents, no PHP 8 / Laravel 9+ compatibility story, and a PSL snapshot old enough to mis-handle .app, .dev, .zip, and private suffixes.
• What we do instead: define DomainParser as our own contract; implement with a maintained PSL parser that ships or caches a current list; register it in our own provider (~50 LOC). Pin the PSL refresh to a scheduled job so staleness is a monitored signal rather than a surprise.
• Escape hatch: if we're mid-sprint and the only goal is log enrichment, copy the provider pattern locally — but don't put the package in composer.json.

The one-line framing to reuse: the requirement is real and cheap to satisfy; this package is stale glue, so we'll own the glue and rent the data.