Polyfill Php73 Laravel Package

Product Decisions This Supports

This is a compatibility enabler, not a feature. It doesn't unlock roadmap items on its own — it removes a specific blocker so work already planned can ship on the PHP version you actually run in production.

• Deferring a PHP runtime upgrade. If the platform team can't move prod off 7.1/7.2 this quarter (shared hosting, legacy ops contract, an unmaintained extension), this package lets feature teams keep writing modern array/JSON/timing code instead of freezing on old idioms. That's a schedule decision: buy ~two quarters of runway for the cost of one composer require.
• Shipping a Laravel package with a wide install base. If you publish a package, supporting PHP 7.1+ materially expands the addressable market of Laravel apps that can install it. The polyfill lets you keep "php": ">=7.1" in require while writing PHP 7.3-style code unconditionally — a distribution decision, not a code-style one.
• Build vs. buy: buy, unambiguously. The alternative is hand-rolling array_key_first/array_key_last/is_countable/hrtime/JsonException shims in app/helpers.php. That's maybe 40 lines of code you now own, test, and defend against redeclare conflicts. Symfony maintains this for free under MIT with a decade of provenance. Never build this.
• Unblocking a JSON error-handling standard. JsonException being available on 7.1/7.2 means you can standardize one decode boundary with consistent catch (\JsonException $e) semantics across a mixed-version fleet — a real architectural cleanup that would otherwise be deferred until every environment upgrades.
• Instrumentation without new vendors. hrtime() enables monotonic duration metrics (queue jobs, middleware) on old runtimes, so observability work isn't gated on the PHP upgrade or on adopting a Prometheus client.
• It does not support: any decision involving PHP 7.3 syntax (typed properties, trailing commas in calls, flexible heredoc, list() references). No autoloaded file can backport parser features. If the blocker is syntax, the answer is "upgrade PHP," and this package will not help — say so early to avoid a wrong turn.

When to Consider This Package

Adopt when all of these are true:

• At least one environment you must support (prod, a customer's server, a CI matrix leg, a package consumer's floor) runs PHP 7.1 or 7.2 — the package requires PHP >= 7.1 and cannot rescue 5.6/7.0.
• The specific gap is one of exactly five APIs: array_key_first, array_key_last, hrtime, is_countable, JsonException.
• You've run composer why symfony/polyfill-php73 and it isn't already present transitively. Laravel's graph commonly pulls in sibling polyfills; if it's already there, just use the functions and skip the decision entirely.
• You've grepped for hand-written shims (grep -rn "function array_key_first" app/) — Composer loads dependency autoload files before your root package's, so a duplicate shim is a fatal Cannot redeclare.

Look elsewhere when:

• Every environment is already 7.3+. The package buys literally nothing. This is the most common case for current Laravel work and the fastest "no."
• The blocker is syntax, not functions. Wrong tool; only a runtime upgrade solves it.
• You need JSON_THROW_ON_ERROR behavior. The polyfill ships the class, not the engine semantics. You still need a wrapper gated on defined('JSON_THROW_ON_ERROR'). Adopt it, but budget for that helper and don't let anyone assume catch (\JsonException) alone makes json_decode throw on 7.2.
• You want sub-microsecond timing fidelity on old runtimes. hrtime()'s fallback is coarser than native. Fine for durations measured within one process; don't compare absolute values across a mixed-version fleet.
• You're below PHP 7.1, or you're considering stacking several polyfills speculatively. Autoload cost is nanoseconds per request, but "five polyfills just in case" is a dependency-hygiene smell worth pushing back on.
• Compliance requires a hard pin with no automated update path — the API has been frozen for years and recent releases are literally "no significant changes," so pinning buys nothing and rots.

Guardrails to attach to any adoption: set config.platform.php in composer.json to the production runtime (e.g. 7.2.34) so resolution doesn't pull 7.3+-only libraries, and separately point PHPStan/Psalm at the language level you're writing (phpVersion: 70300) so static analysis doesn't flag native function names as undefined. Those are two different numbers and conflating them causes real confusion. Use a ^1.20 caret constraint, not a hard pin. And open a removal ticket the day you add it.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a free, MIT-licensed, Symfony-maintained compatibility library that lets our code use five modern PHP functions even though our servers run an older PHP version. It costs nothing at runtime, requires no infrastructure change, and — critically — it is invisible and removable: the functions keep the same names and signatures, so when we eventually upgrade PHP, deleting it is a one-line composer remove with zero refactoring. It is not a strategic bet; it's a short-term bridge that protects the delivery schedule while the runtime upgrade is sequenced. The decision to make is not "should we adopt this" but "when do we remove it" — and we should name that date now so it doesn't become permanent sediment.

For engineering — the substance:

• What you get: array_key_first, array_key_last, hrtime, is_countable, JsonException. Nothing else. It does not backport 7.3 syntax — no typed properties, no trailing commas in calls, no flexible heredoc. Don't let that expectation take root.
• Integration is one command, and the first step is verifying you don't already have it transitively. The whole contract lives in a ~100-line bootstrap.php — read it instead of hunting for docs.
• Two things will bite you: writing a shim in app/helpers.php after installing (fatal redeclare), and assuming JsonException makes json_decode throw. It doesn't — gate JSON_THROW_ON_ERROR on defined() and centralize decode in one helper.
• Package authors: this is the highest-leverage use. Write modern code, keep your PHP floor at 7.1, run a 7.2 + 8.2 CI matrix, and add one assertion on the 7.2 leg that the functions exist so nobody silently breaks the low-PHP target.
• Ownership: assign someone to watch Composer advisories. Releases here are frozen, so the real risk isn't a bad update — it's nobody ever removing the dependency after we no longer need it.