Interoperability Laravel Package

Product Decisions This Supports

• Whether to standardize on PSL value types at all. This package is not a standalone capability — it is the sanctioned conversion seam that only matters if we adopt php-standard-library types (Str, Vec, Dict, DateTime, etc.). The real decision it informs is "PSL inside, native PHP at the edges," and this package is the named contract for that boundary rather than an ad-hoc convention.
• Where to draw the boundary between domain types and framework types. Laravel's edges all speak stdlib: Eloquent casts, API resources, queue payloads, cache values, Blade formatting, DateTimeInterface, and intl formatters. These interfaces give that translation a single home instead of scattering ->toString() and new DateTimeImmutable(...) through controllers and models.
• Build vs. buy for glue code. Any PSL adoption requires hand-written conversion between PSL and stdlib/intl. Using the upstream interfaces instead of a bespoke internal helper keeps that glue recognizable to future hires and to other teams, and makes it replaceable.
• Reversibility of the PSL bet. Centralizing conversions means that if we later drop PSL, we change one adapter layer rather than hunting casts across the codebase. That lowers the cost of an otherwise speculative architectural choice.
• Roadmap triage. This is plumbing, not a feature. It should never appear as a roadmap line item; it is a rider on a PSL pilot decision and should be scoped and staffed accordingly (near zero effort).

When to Consider This Package

Adopt when:

• PSL types are already in composer.lock (typically via the main php-standard-library metapackage) and we need to hand data to stdlib/intl consumers — Eloquent casts, JSON resources, third-party SDKs, IntlDateFormatter/NumberFormatter.
• Multiple teams or internal packages need PSL-to-native conversion and we want one shared contract instead of duplicated helpers.
• We want conversion points to be explicit and testable rather than implicit in model accessors.

Look elsewhere, or skip entirely, when:

• We are not using PSL types. In that case this package delivers zero value — it adds a dependency for interfaces nothing implements.
• We need framework or ecosystem interop. Despite the name, this is not a PSR-11/PSR-15 bridge, not a Symfony adapter, and not an abstraction for loggers, message buses, HTTP clients, or caches. Laravel's own Illuminate\Contracts\* already covers those concerns; do not let "interoperability" be misread as "polyglot framework glue."
• We need Eloquent/Collection/Carbon interop. Laravel's casts and Carbon handle that today; PSL conversion does not displace them.
• We need proven ecosystem support. One star, zero dependents, and releases that just link back to the monorepo mean we would be an early adopter. Treat this as a bet on the PSL maintainers' diligence, not on community validation.
• Documentation depth is a requirement. There is no standalone guidance on conversion semantics — nullability, precision, locale behavior, or round-tripping — so we would own that analysis ourselves.

Adoption gate (all should hold): PSL already present transitively; we can pin the PSL major and take coordinated upgrades; boundary serialization has test coverage; and someone owns the adapter layer.

Bottom line: conditional no by default. Reconsider only alongside a deliberate PSL pilot, not as an independent addition.

How to Pitch It (Stakeholders)

Executives: Do not fund this as a project. It is a small MIT-licensed interface package inside the PHP Standard Library whose only job is converting between PSL's specialized types and plain PHP/intl. It enters our stack only if we choose to use PSL types, and then it is the standard way to hand that data back to everything else — the adapter that keeps a specialized internal type compatible with ordinary PHP. Cost is near zero and there is no lock-in; the benefit is less bespoke glue and a cheaper exit if we reverse the decision. The honest risk is ecosystem maturity, not licensing or cost.

Engineering: Be precise about scope before anyone commits. This is not a PSR bridge, Symfony adapter, or message-bus abstraction. It is interfaces for converting PSL types to and from stdlib/intl equivalents. Practical guidance:

• Prerequisite: confirm PSL is already a dependency. If it isn't, stop — the package is inert without it.
• Where it goes: at the seams only — Eloquent casts, API resources, queue payloads, cache values, intl formatting. Keep PSL types in the domain; convert at the edge.
• Caveats to plan for: single-digit stars, zero dependents, docs delegated to the upstream PSL site, and releases that track the monorepo changelog. Pin the PSL major version, read the main repository's release notes rather than this package's, and keep the adapter layer thin and covered by tests so an upstream contract change surfaces as a failing test rather than a runtime surprise.
• What it buys us: one recognizable conversion contract instead of N team-specific helpers, and a single place to change if we drop PSL later.