Polyfill Php84 Laravel Package

Product Decisions This Supports

• Upgrade-Path De-Risking (primary impact of v1.43.0): This release is a parity/hardening release, not a feature release. The fixes align polyfilled behavior with native PHP 8.4 (mb_trim, Normalizer, grapheme_levenshtein, grapheme_str_split, bcmath validation, odbc_connection_string_should_quote, uuid constants). That directly supports the "develop on polyfill, ship on native" strategy: the same code path behaves identically on PHP ≤8.3 and ≥8.4, so incremental migration stays low-risk.
• Roadmap Alignment: No change to Laravel's PHP compatibility strategy and no new API surface. Treat v1.43.0 as maintenance on the existing roadmap line (supersedes v1.38.1); no roadmap slots need to be re-planned.
• Build vs. Buy Decision: Strengthens the "buy" case. The work in this release (bug-for-bug alignment of mb_trim with native, intl extension parity on ill-formed UTF-8, bcmath number validation) is exactly the invisible maintenance burden teams underestimate when writing their own polyfills. MIT license, no vendor lock-in.
• Key Use Cases (unchanged in scope, revised in risk profile):
  • Data Processing: array_find/array_all untouched by this release — still the clean replacement for collect()->filter()->first().
  • Deprecation Management: #[Deprecated] unchanged; safe to keep using for gradual API phase-outs.
  • Internationalization: Now more trustworthy — mb_trim, Normalizer, and intl handling of ill-formed UTF-8 match native, which matters for multilingual input validation and normalization.
  • Financial/Math Operations: Behavior change risk — bcmath number validation is now stricter and aligned with native; inputs previously tolerated by the polyfill may now be rejected.
  • Database Stability: odbc_connection_string_should_quote() and uuid constants aligned with native.
• Decision on the table: not "adopt or not" (already adopted) but "upgrade from 1.38.x to 1.43.0 now, or pin". Recommendation: upgrade with a targeted regression pass on validation paths (bcmath inputs, Unicode/form normalization, grapheme splitting on malformed strings).

When to Consider This Package

Adopt When:

• Your Laravel project targets PHP ≤8.3 but requires PHP 8.4 features (e.g., array_find, Deprecated attribute) for new functionality.
• You’re on Laravel 9.x/10.x and need to future-proof against PHP 8.4+ dependencies without an immediate upgrade.
• Your app processes multibyte strings (CJK, Arabic, emoji) and needs Unicode-aware trimming/splitting/normalization (mb_trim, grapheme_str_split, Normalizer).
• You handle financial calculations (bcdivmod, bcpow-style math) with high precision needs.
• Your team uses Symfony components (e.g., HttpClient, String) that implicitly rely on these polyfills.
• You’re modernizing legacy code incrementally and need byte-identical behavior between pre- and post-upgrade environments.

Upgrade Immediately (from ≤1.38.x) When:

• You depend on mb_trim / Normalizer for form or API input sanitation — the 1.43.0 alignment fixes divergence from native behavior.
• You accept user-supplied UTF-8 into grapheme_* or intl-backed code — ill-formed UTF-8 handling now matches the intl extension.
• You rely on grapheme_levenshtein / grapheme_str_split argument validation — these now validate arguments instead of silently misbehaving.

Look Elsewhere / Test Before Upgrading If:

• Your PHP version is ≥8.4 (polyfills are redundant; upgrade directly).
• You pass lenient or malformed numeric strings to bcadd/bccomp/etc. — stricter validation may surface as exceptions or changed results. Add fixtures before rollout.
• You require custom array functions beyond array_find/array_all.
• Performance benchmarks show polyfill overhead is unacceptable on hot loops (unchanged by this release — re-benchmark only if you changed call sites).
• Your hosting environment lacks PCRE ≥10.44 (still required for grapheme_str_split).
• Your use case is niche (CURL_HTTP_VERSION_3, HTTP/3 experiments).

How to Pitch It (Stakeholders)

For Executives:

*"This is a stability release, not a feature release — and that's the good news. v1.43.0 makes our polyfilled PHP 8.4 functions behave identically to native PHP 8.4, which is the whole point of our incremental upgrade strategy. Benefits:

• Lowers upgrade risk: code tested on PHP 8.3 today will behave the same when we move to 8.4 — no surprise rewrites.
• Protects global markets: mb_trim, Normalizer, and intl fixes stabilize multilingual input handling (critical for [Market X]).
• Zero cost: MIT license, no vendor lock-in, no new dependencies or hosting requirements.
• Effort: ~1 sprint-day of engineering regression testing, no product downtime expected. Recommendation: Approve the minor-version bump; prioritize regression testing on financial/validation paths, then roll out to high-traffic modules. Budget: $0 plus a small QA window."

For Engineering:

*"v1.43.0 (supersedes v1.38.1) is a parity/bugfix release — no new functions, no deprecations, no API removals. What changes:

• mb_trim, Normalizer, uuid constants, odbc_connection_string_should_quote() now align with native PHP 8.4 behavior.
• grapheme_levenshtein() / grapheme_str_split() argument validation fixed — expect exceptions on invalid arguments where behavior was previously undefined.
• bcmath number validation fixed/stricter, matching native.
• intl parity on ill-formed UTF-8 — grapheme/intl functions now behave like the extension for malformed input.

Action Items:

1. Bump the dependency:

   "require": {
     "symfony/polyfill-php84": "^1.43"
   }
   

2. Add regression tests before merging:
   • mb_trim(null) and mb_trim() on padded/normalized form inputs.
   • Normalizer::normalize() on composed/decomposed and ill-formed UTF-8 payloads.
   • grapheme_str_split('👨‍👩‍👧‍👦') plus invalid-argument cases (assert the new exceptions).
   • bcadd/bccomp/bcdiv with user-supplied strings, including '', '1,5', '1e3', and leading +.
3. PCRE check (unchanged requirement):

   if (version_compare(PCRE_VERSION, '10.44') < 0) {
       Log::warning('PCRE <10.44: grapheme_str_split may fail.');
   }
   

4. #[Deprecated] usage unchanged — no migration needed for existing tags.
5. Do not treat as a breaking change, but gate the merge on the bcmath and UTF-8 regression suites; those are the only paths where behavior can shift."

For Security/Compliance:

*"This release improves behavioral consistency in input handling:

• Normalizer and intl ill-formed UTF-8 handling now match the native extension, reducing divergence risk in validation and sanitization paths (relevant to Unicode-based bypass and injection testing).
• Stricter bcmath validation means malformed numeric input is rejected rather than coerced — a net security gain for financial and quota logic.
• odbc_connection_string_should_quote() alignment hardens connection-string construction.
• Standardized #[Deprecated] support is unchanged and continues to align with PSR-style deprecation practice. Recommendation: Approve for production. Prioritize regression testing on any endpoint that sanitizes user-supplied Unicode or parses user-supplied numbers, then roll out broadly."

For Data/Analytics:

*"array_find/array_all behavior is unchanged in v1.43.0 — existing dashboard and role-filtering optimizations remain valid:

$admin = array_find($users, fn($u) => $u['role'] === 'admin');

What to watch: bcmath validation is now stricter, so any analytics pipeline feeding loosely-typed numeric strings into bc* functions may see new rejections or changed results. Audit ETL/job code that parses monetary or metric values from CSVs, spreadsheets, or user exports, and add fixtures for edge cases ('', '1,5', '1e3', leading +). Use Case: Re-run [Analytics Dashboard] aggregation jobs in staging before promoting; expect no change for cleanly-typed inputs."

For DevOps/Infrastructure:

*"Key considerations:

• No new platform requirements: PCRE ≥10.44 remains the only environmental gate (grapheme_str_split); no new extensions, no new services.
• Patch-level bump, backward compatible: no breaking API changes; safe to roll through normal dependency update cadence.
• Behavior shifts localized: bcmath validation and Unicode/Normalizer parity are the only observable changes — monitor validation-error rates and 4xx/5xx on form and payment endpoints after deploy.
• Polyfill overhead: unchanged; re-benchmark only if call sites changed. Recommendation: Deploy to staging first, watch validation error rates and response times on /api/users and payment/checkout paths for one cycle, then promote to production."