Helpers Laravel Package

Product Decisions This Supports

• Framework upgrade sequencing (the core decision). laravel/helpers converts a "big bang" Laravel 5.8→current migration into two independently shippable releases: (1) framework bump + add this package, fix only genuine breaking changes; (2) a later, schedulable helper-refactor PR that removes it. This is a roadmap decision, not a coding one — it lets you place the upgrade in a sprint without also funding a mechanical cleanup sprint in the same window.
• Build vs. buy vs. skip. The capability is trivial to build (a file of if (! function_exists(...)) shims forwarding to Arr::/Str::), but you should buy: it is first-party Laravel, MIT, and its illuminate/support constraint is bumped ahead of each framework release (through ^13.0 in v1.8.3), which is the maintenance burden you actually want to avoid. Building your own means owning that version-matrix upkeep forever.
• Budget sizing for modernization. The package gives you an escape hatch that buys time to measure the debt. A repo-wide call count of array_get / str_slug / studly_case etc. turns "modernization" into a number — that number decides whether the refactor is a two-day sweep or genuine rework, and therefore whether it's a sprint line item or a background task.
• Scope control / freeze-new-usage policy. Because the README states outright "We are not accepting new helpers," adopting it is a deliberate, bounded decision. Pair adoption with a CI baseline that fails the build when helper call counts grow — the package is a bridge, not a house style.
• Third-party and acquired-code compatibility. The strongest product justification: dormant Composer dependencies, vendor plugins, and acquired codebases that call array_get and cannot be patched. This is a ship-blocker you can resolve in one composer require rather than a fork-and-maintain decision.
• Exit-path planning. Adoption implies a documented exit: automated conversion via Rector rules (near one-to-one mapping: array_get→Arr::get, str_limit→Str::limit), golden tests pinning the helpers whose legacy and modern behavior are not byte-identical (dot-notation array_get, non-ASCII str_slug), then removal. That plan is a deliverable, not an afterthought — otherwise "temporary" becomes permanent.

When to Consider This Package

Adopt when all of these hold:

• You are mid-upgrade on an existing Laravel app or package set that predates the 5.8 helper deprecation, and application or vendor code still calls the global helpers.
• You want the upgrade PR to stay a framework/dependency diff so it stays reviewable and bisectable — the helper refactor should not ride along.
• Your target framework version is covered by the package's illuminate/support constraint (verify with composer show laravel/helpers; v1.8.3 covers ^13.0, v1.7.2 covers Laravel 12). If the range doesn't overlap your framework, bump the package tag rather than forcing the constraint.
• At least one helper call site is in code you cannot modify. This is where the package is not merely convenient but necessary.
• You accept the operational detail that it must live in require, not require-dev, if any production code path calls a helper — and that long-lived workers (Horizon, queue) need a restart after install.

Look elsewhere — or skip entirely — when:

• Greenfield or already-modern code. Zero helper call sites means the package is pure dependency surface with no payoff. Use Arr:: / Str:: / Str::of() directly.
• You need helpers that don't exist. The API is frozen by design. If a requested helper isn't in the 5.8 set, this package will never provide it; write a local utility class or use the Str fluent API.
• You need behavioral parity guarantees. Every helper delegates to the modern implementation, and the package explicitly will not patch divergences. If legacy quirks matter, pin them with tests before you convert — do not file issues.
• You're treating it as a permanent dependency. If the team has no intent to fund the exit, you're accumulating a shim layer with a version matrix attached, and the long-term cost lands on whoever does the next major upgrade.
• Static analysis is non-negotiable and un-budgeted. PHPStan/Larastan and IDEs don't know these globals; you'll need a stub/_ide_helper file for the transition period. That's small but real work.

How to Pitch It (Stakeholders)

To executives: This is a one-line dependency that de-risks and de-scopes a platform upgrade. Instead of a single risky release that changes both the framework and hundreds of code call sites, we split it: the framework upgrade ships first with laravel/helpers installed, and the code cleanup becomes a separately scheduled, measurable piece of work we can size before committing to it. It's first-party Laravel code, MIT-licensed, actively version-bumped ahead of each framework release, and reversible — removing it is a composer remove once call counts hit zero. Total cost is near zero; the alternative is either a larger, riskier upgrade PR or forking a vendor package we don't control.

To engineering: Zero-config — Composer files autoload, no service provider, no config, no publishing. It re-registers the 5.8 global helpers and each one simply forwards to Arr:: / Str::. Three rules: put it in require (not require-dev), restart queue workers after install, and freeze new usage with a CI baseline or a PHPStan/PHP-CS-Fixer banned-function rule so the count only goes down. Convert per-file rather than per-helper-name to keep diffs reviewable, automate the bulk with Rector, and pin the handful of non-identical behaviors (array_get dot notation, str_slug with non-ASCII) in tests before deleting the package. Where unmodifiable vendor code forces the dependency, document which package and why in composer.json or a tech-debt note so nobody rips it out and breaks production.

Risk statement to include in the pitch: the API is frozen ("We are not accepting new helpers") and behavior is inherited from Arr/Str with no patches — this is a compatibility bridge with a planned exit, not a strategic dependency. Adopt it with a named owner and a removal criterion, not indefinitely.