# laravel/helpers: a compatibility shim for the Laravel 5.8 helpers

> laravel/helpers is a small Composer package that keeps the global helper functions from Laravel 5.8 working in a current Laravel release. It is a migration bridge rather than a toolkit, the project states that it does not accept new helpers, and its long term value is as a checklist for removing the last of them.

**laravel/helpers** — Provides backwards compatibility for helpers in the latest Laravel release.

- Repository: https://github.com/laravel/helpers
- Stars: 809 · Forks: 44
- Language: PHP
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/laravel-helpers

## What the package actually is

laravel/helpers is a Composer package that provides a backwards compatibility layer for Laravel 5.8 helpers in the latest Laravel release. That single sentence covers the whole of it, and it is worth sitting with, because the name suggests a helper library and it is not one.

The helpers in question are the global functions that older Laravel applications call without a namespace, the array and string functions that lived in the global scope before the framework moved them into the Arr and Str classes. This package makes those functions work again, so an application written against Laravel 5.8 can move to a current release without rewriting every call site at once.

That makes it a migration aid, and it is best understood as a temporary scaffold rather than a dependency you want to keep. A team that installs it is buying time: the application boots, the tests pass, and the work of moving to the class based API can be scheduled and done in reviewable pieces instead of as one enormous pull request.

The repository matches the shape of the job. It is small, with src/ holding the package, tests/ holding the suite, composer.json for the package definition, phpunit.xml.dist and phpstan.neon.dist for the test and static analysis configuration, and a .styleci.yml for formatting. There is a CHANGELOG.md, which for a package of this kind is the most useful file in the repository, because it records exactly which versions changed which helper behaviour.

## Why no new helpers are accepted

The README states in bold that the project is not accepting new helpers, and that single line defines the package's policy better than any feature list could.

The reason follows from what the package is. A compatibility layer exists to preserve an interface that is on its way out. Every function it carries is one the framework has already moved to a class, and the project has no reason to widen the surface of deprecated API. Accepting a new helper would mean maintaining a global function that the framework does not have, which is a different job with a different maintenance profile.

For an adopter this matters in one practical way: you cannot extend the shim. If your application has a helper that was never in Laravel 5.8, or one you have written yourself, this package is not the place for it. The supported path for new code is the class based API, and the documentation says so by pointing at the Laravel website for the equivalent methods on the Arr and Str classes.

It also tells you what the end state looks like. The package will eventually be removable, because that is what a deprecation path is for. A team that adopts it should treat it as a tracked item rather than a permanent addition, and the CHANGELOG is where you will see whether the framework has moved on again.

## The Arr and Str classes are the real destination

The README does not document a single helper method of its own, and that is the most informative thing about it. Instead it points readers to the official documentation for the equivalent methods on the Arr and Str classes on the Laravel website.

So the mental model is a wrapper. The old global function and the new class method are the same operation, and the class method is the one the framework maintains. When you are reading the documentation to understand what a helper does, you are effectively reading the Arr and Str documentation with an extra layer in front.

That framing has a practical consequence for how you use the package. Two teams can install the same shim and end up in different places, depending on how they treat it. One treats it as a permanent shim and never migrates, and pays for it forever. The other treats it as a to-do list, and the number of remaining call sites is a metric they can watch. The package supports the second approach better, because the old names are recognizable in a diff, and a pull request that replaces a handful of global calls with their class equivalents is easy to review.

There is also a behavioural question worth checking rather than assuming, since the shim delegates to methods that have been revised over several Laravel releases. A function frozen at 5.8 semantics and a method that has since been improved are not always identical, and the equivalence the README asserts is about intent rather than about every edge case.

## Installing it with Composer

The installation is the standard Composer require, and the README gives it as a single command:

```bash
composer require laravel/helpers
```

There is no configuration step, no service provider to register and no environment variable to set. That is the whole of the setup, and it follows from the design: the package is a set of global functions that were removed from the framework, so having them present is the entire feature.

The absence of setup is also what makes it useful in an emergency. When an upgrade is blocked because a hundred call sites reference functions that no longer exist, adding one line to composer.json and running the install gets the application running again in a way that no other refactoring task can.

What to check after installing is the dependency situation, which the README does not spell out and which composer.json in the repository would settle. The relevant questions are the PHP version constraint and the Laravel version constraint, because a compatibility shim has to be allowed to install alongside the framework version you actually run. If the constraint on the framework is narrow, the shim that exists to help you upgrade may itself be blocked by the upgrade it is meant to enable.

The remaining README sections are the standard ones you would expect from a package in the Laravel organisation: a link to the official documentation, a pointer to the contribution guide in the Laravel documentation, a code of conduct, and a security policy with the request to review it for how to report vulnerabilities.

## What the repository says about the project

The tree gives the useful signals for judging whether this is a package you want running in production.

There is a CHANGELOG.md, and for a compatibility shim a changelog is the primary interface. You need to know, before you upgrade the framework, whether the version of the shim you have pinned supports the release you are moving to, and whether the shim itself changed behaviour in the upgrade. The repository also carries a phpstan.neon.dist and a phpunit.xml.dist, which say that the package is statically analysed and unit tested, and a .styleci.yml for formatting, which is how the Laravel organisation applies its own code style across packages.

The tests/ directory is the part worth looking at when you want to know what the package actually promises. A compatibility shim is a set of behavioural equivalences, and each equivalence is a claim that the wrapper produces the same result as the underlying method. Those claims are what the test suite should be asserting, and if you are adopting the package in an application with unusual data, the tests are where you find out which behaviours were pinned and which were not.

The MIT licence and the standard Laravel contribution, conduct and security processes complete the picture. The licence is permissive, and the security policy link tells you there is a defined route for reporting a vulnerability in the package, which matters more for a shim than for most libraries, since a bug in a compatibility wrapper can reintroduce a problem the framework had already fixed.

## When the shim is the wrong answer

Three situations point elsewhere.

The first is a new application. There is no legacy call site to preserve, so the shim adds a dependency and a set of global functions in exchange for nothing. New code should call the Arr and Str classes directly, and the README points at exactly those methods.

The second is a codebase where the old helpers are threaded through the test suite and the templates. The shim makes the application boot, but it does not tell you where the calls are, and the migration cost stays hidden until somebody decides to do the work. If your plan was never to migrate, installing the shim is the easiest way to make that decision disappear.

The third is a framework version the shim does not cover. The package tracks the latest Laravel release, and a compatibility layer for a specific old release is exactly the thing that stops being maintained once the framework it targets falls out of use. If you are on a version of Laravel that is itself out of support, this package is unlikely to be the answer either.

The honest summary is that laravel/helpers is a well placed stopgap. It makes a specific, painful upgrade possible without a large risky diff, it is small, it is tested, and it says plainly that it is finished as a design. What it cannot do is tell you when to remove it.

## Conclusion

Adopt laravel/helpers if you are running a current Laravel release on an application that still calls the Laravel 5.8 global helpers and you want the upgrade to stop being a blocker, at the cost of one more dependency and a lingering set of global functions. Do not adopt it in a new project, since it exists to delay a migration rather than to enable one, and do not treat it as a general helper library. Verify three things first: how many call sites actually use the old helpers, because the shim keeps them working without telling you where they are; whether the framework version you run accepts the package at all, since this is a compatibility layer for the latest release and the composer constraints decide that; and which behaviour differences matter, since the replacement methods on the Arr and Str classes are the documented equivalent and the old function is a wrapper around them. The licence is MIT, the last push was on 2026-10-16, and the newest release is v1.8.3 dated 2026-03-17.

## FAQ

### What does the laravel/helpers package do?

It provides a backwards compatibility layer for Laravel 5.8 helpers in the latest Laravel release, so global helper functions from the 5.8 era keep working in a current application. It is a migration aid rather than a helper library.

### How do I install laravel/helpers?

Run composer require laravel/helpers. There is no configuration step, no service provider to register and no environment variable to set, because the presence of the restored global functions is the whole feature.

### Can I add my own helper functions to laravel/helpers?

No. The README states in bold that the project is not accepting new helpers, which follows from the package existing to preserve an interface the framework has already moved to the Arr and Str classes.

### Where is the documentation for these helper functions?

The README does not document the helpers itself and instead points to the documentation for the equivalent methods on the Arr and Str classes on the Laravel website, since the old functions delegate to those class methods.

### What licence is laravel/helpers released under?

The MIT license, with the terms in the LICENSE.md file at the repository root. The repository also carries a CHANGELOG.md, phpstan.neon.dist, phpunit.xml.dist and a .styleci.yml configuration.

## Sources

- [Issues](https://github.com/laravel/helpers/issues)
- [laravel/helpers on GitHub](https://github.com/laravel/helpers)
- [License: MIT](https://github.com/laravel/helpers/blob/master/LICENSE)
- [README](https://github.com/laravel/helpers/blob/master/README.md)
- [Releases](https://github.com/laravel/helpers/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/laravel-helpers