Tld Support Laravel Package

Technical Evaluation

Architecture fit. layershifter/tld-support is not a feature library — it is the shared foundation beneath TLDExtract (public-suffix-aware domain parsing) and TLDDatabase (the bundled Public Suffix List data). In a Laravel codebase it appears as a transitive dependency, pulled in when a developer adds TLDExtract for domain/email/host parsing. It is a pure-PHP utility layer: rule matching, suffix normalization, and likely IDN/punycode handling. Nothing about it is Laravel-specific; there is no service provider, config, facade, or framework coupling. That is architecturally clean but also means it delivers no integration value on its own — it is only as good as the package that requires it.

Integration feasibility. Composer-installable in one line, PSR-4 autoloaded, Apache-2.0 (permissive, commercially safe, only a NOTICE-retention obligation). The real feasibility question is version constraints, not code: a 2016-vintage package typically declares php: >=5.5 or similar with no upper bound, which resolves on PHP 8.1–8.3 but is functionally untested there. Where it fails, it fails at Composer resolution time (if the constraint is capped) or as a runtime deprecation (dynamic properties, implicit nullable params, curly-brace string offsets). Practical install cost is near zero; certification cost is non-zero.

Technical risk.

• Abandonment (high): archived repo, last release June 2016, no security response path. Any CVE-adjacent defect is permanently ours to fix.
• Correctness surface (medium): TLD parsing is deceptively subtle — wildcard rules (*.ck), exception rules (!www.ck), and multi-label suffixes (co.uk, s3.amazonaws.com) are exactly where silent misparses occur. A wrong answer is not an exception; it is a plausible-looking wrong string.
• Data staleness (external): the PSL data lives in TLDDatabase, not here — so this package is logic, not data. That slightly lowers the risk profile but does not eliminate it, since logic bugs against new rule shapes (e.g., new PSL syntax) cannot be patched upstream.
• Low blast radius otherwise: no I/O, no network, no filesystem, no credentials. Small attack surface.
• Signal quality: 38 stars and 0 recorded dependents understate real usage (it is a hard dependency of TLDExtract, which is widely used) but the metric is not evidence of health.

Key questions to answer before committing.

1. What is the actual public API surface — is it a stable value object (e.g., Domain/Suffix) or a grab-bag of static helpers? This determines whether we can shim it behind our own contract.
2. Is any version of TLDExtract we'd realistically use pinned to a tld-support major that is unmaintained? Check composer why layershifter/tld-support.
3. Does it require ext-intl or ext-mbstring, and are those present in our runtime images and CI?
4. Does the PSL matching do linear scans per call, and is it called per-request (e.g., tenancy resolution, cookie scoping) or only at write time?
5. Is there a maintained replacement that is a drop-in for our call sites, and what does that migration cost?

Integration Approach

Stack fit. Composer + PSR-4 + Apache-2.0 fits Laravel 8–11 without friction. The absence of framework coupling is a genuine plus: no service provider to boot, no config to publish, no container bindings to reason about. It will not conflict with Laravel's own helpers.

Recommended posture: do not install directly. Treat it as a transitive artifact. If a feature needs PSL-aware parsing, evaluate the maintained alternatives first — jeremykendall/php-domain-parser (actively maintained, explicit PSL versioning and update path), or symfony/polyfill-intl-idn for the IDN half plus our own PSL loader. Only accept tld-support if it arrives bundled with a TLDExtract version we have deliberately chosen.

Compatibility validation. Prove PHP 8.x behavior empirically, not by inspection: install in a scratch branch, run the full test suite against PHP 8.1/8.2/8.3, and run a corpus test of ~200 real domains (including *.ck, !www.ck, co.uk, IDN, trailing dots, uppercase, and malformed input) comparing outputs to a known-good reference. Treat any E_DEPRECATED output as a defect, not noise — it is the leading indicator of a future fatal.

Migration path if already in use.

1. Inventory call sites: composer why, then grep for direct use versus use through TLDExtract.
2. Introduce an internal seam — a DomainParser interface in our app with one adapter over the package. This is cheap now and turns a future swap into a single-file change.
3. Pin the version explicitly ("layershifter/tld-support": "1.*") so an accidental transitive bump cannot move it.
4. If we must retain it, fork to a private VCS repo, declare php: ^8.1, add CI, and carry the patch delta as our own release. Budget for this as ongoing cost, not a one-time task.

Sequencing. (a) API surface review → (b) PHP 8 corpus validation → (c) seam/adapter introduction → (d) decide keep-vs-replace → (e) if keep, fork + CI + SCA allowlist entry; if replace, migrate behind the seam and delete the dependency. Do (a)–(c) in a single short spike; the decision gate is (d).

Operational Impact

Maintenance. Effectively zero upstream maintenance forever — the repo is read-only. All future work is ours. The dependency is small enough that "vendor and own it" is realistic (likely a few hundred lines), but it must be scheduled, not assumed. Add it to the dependency register with an explicit owner and a review date; otherwise it becomes invisible until it breaks.

Support. No upstream security advisories will ever be issued, so dependabot/composer audit silence is not evidence of safety — it is evidence of no one watching. Add the package to the SCA allowlist only with a documented rationale, and re-review on Laravel/PHP major upgrades. Apache-2.0 obliges us to preserve the NOTICE file if we redistribute; internal use is unaffected.

Scaling. Negligible infrastructure cost: pure in-memory string logic, no I/O, no network, no state. The only scaling concern is per-request invocation. If parsing runs on every request (tenant subdomain resolution, cookie domain scoping), make the parser a singleton and cache results — domain→registrable-domain is a tiny keyspace and highly cacheable in Laravel's cache or an in-process array. Confirm the matcher is not doing a linear scan of the full PSL per call; if it is, memoize above it.

Failure modes.

• Silent misparse (highest severity): co.uk treated as registrable → cookie set on the wrong scope, session leakage across tenants, or a tenancy router sending traffic to the wrong tenant. No exception is raised; the bug surfaces as a support ticket weeks later.
• Over-permissive email/domain validation: accepts inputs it should reject, or vice versa, with no error trail.
• Composer resolution failure on a PHP major upgrade, discovered at deploy time — mitigate with an explicit pin and a CI job on the target PHP matrix.
• Fatal on missing ext-intl in a slimmed production image that differs from CI.
• Deprecation-to-fatal drift across PHP minor versions, silently accumulating.

Ramp-up. Very low for engineers — the API is small and the domain (public suffix parsing) is well documented externally via publicsuffix.org. The genuine ramp-up risk is organizational: there is no upstream documentation, no active issue tracker, and no maintainer to ask. Every question becomes an internal investigation. Mitigate by writing a short internal ADR at adoption time capturing the API surface, the PHP 8 validation results, and the replacement candidate — so the next engineer inherits a decision rather than a mystery.