illuminated/helper-functions
Illuminated/helper-functions is a Laravel and PHP package offering a practical collection of global helper functions for arrays, strings, URLs, paths, and common application tasks. It helps developers reduce boilerplate and write cleaner, more expressive code.
Install with Composer:
composer require illuminated/helper-functions
Laravel's package auto-discovery should register the service provider. If you're on an older Laravel version, add Illuminated\HelperFunctions\HelperFunctionsServiceProvider (check the exact class name in the README) to config/app.php.
Version alignment matters here. This package's major version tracks Laravel's major version: the current 13.x line is the one that declares Laravel 13 support (added in 13.0.0). If you're on Laravel 12, stay on ^12.0; if you're on Laravel 13, use ^13.0. Check the require block in vendor/illuminated/helper-functions/composer.json to confirm the constraints your installed version actually advertises before you plan an upgrade.
The important first step is understanding how the helpers get loaded. Open vendor/illuminated/helper-functions/composer.json and look for a "files" entry under autoload. That's the mechanism that makes plain functions available globally — not a facade, not a service container binding. Once you've confirmed that, open the src/ directory and skim the files. Because this is a grab-bag of small utilities rather than a cohesive framework, the fastest way to learn the API is to grep for function in src/:
grep -rn "^function " vendor/illuminated/helper-functions/src
Your first use case should be a small one: find a piece of inline logic you repeat in a couple of places (normalizing an array key, formatting a string, guarding against nulls) and replace it with the package equivalent. This package shines as a "standard library" of little conveniences, not as a large architectural dependency.
Use them where Laravel helpers already live. These are global functions, so they work anywhere a str_* or array_* helper works: controllers, form requests, Blade templates, migrations, queue jobs, and even plain PHP scripts bootstrapped by Laravel. Don't wrap them in your own facade — that defeats the purpose.
Replace repeated inline expressions. The typical workflow is: spot a repeated ternary or isset() dance in your codebase, check whether the package has a named helper for it, and swap it in. Keep a short note in your team's style guide listing which helpers you've adopted so reviewers recognize them.
Compose with Laravel's native helpers. Since they share the global namespace, you can freely nest them with collect(), data_get(), Str::of(), etc. A common pattern is to use the package helper for the scalar transform and Laravel's fluent Str/Collection objects for the surrounding pipeline.
Blade usage. Because they're global functions, they're directly callable in Blade without @php blocks in many cases:
{{ some_helper($value) }}
Keep Blade usage to presentation-only transforms; push anything with branching logic back into a view model or presenter so it stays testable.
Testing. Treat the helpers as third-party code and do not unit test them. Do test your integration points — a feature test that exercises the controller or Blade view is enough to catch a breaking change after an upgrade. This matters more than usual here: a Laravel major bump means a package major bump, and the two should move together in your composer.json.
Package/library usage. If you're building an internal package, prefer calling the helper only inside your own boundary and re-exposing a named method. That way, if the package is abandoned or the helper changes signature, you have one place to patch.
Upgrading Laravel. Treat the package bump as part of the Laravel upgrade checklist, not a separate chore: bump laravel/framework and illuminated/helper-functions to matching majors in the same branch, run composer update, then run your feature tests. Since 13.0.0 only adds Laravel 13 support (no documented removals), the primary risk is the framework upgrade itself plus anything the release silently changed underneath the "Laravel 13 support" line — diff the src/ tree between tags before assuming it's a no-op.
autoload.files are loaded on every request, whether or not you use them. The cost is small but non-zero. More importantly, every function name is a potential collision with Laravel, Symfony, or another helper package. Before adopting a helper, run grep -rn "function name_of_helper" vendor/ to confirm it isn't already defined elsewhere.^13.0 constraint if you're still on Laravel 12, and do not let composer update drift you onto a major that your framework doesn't support. Match the majors explicitly, and read the require block rather than the README badge.composer require — or after a major upgrade — this is the first thing to check. Adding another helper package alongside this one is the highest-risk scenario.config/helper-functions.php to publish — there almost certainly isn't one. Behavior is fixed at the code level.vendor/ are sometimes missed by PHPStorm's index or by PHPStan/Psalm unless you regenerate stubs or add the src/ path to your analysis config. If your editor shows "undefined function" — especially right after a major bump — run composer dump-autoload and reindex before assuming the package is broken.dd()/dump() inside them means editing vendor/ code — which composer install will overwrite. Instead, wrap the call at your usage site, or copy the function into a local app/Support/helpers.php temporarily when you need to step through it.helpers.php and dropping the dependency.^13.0 on Laravel 13), commit composer.lock, and let your test suite catch behavioral changes on composer update.helpers.php. The cleanest way to extend this package's approach is to add your own app/Support/helpers.php (autoloaded via composer.json files) for project-specific helpers, keeping the third-party ones separate so upgrades stay clean.How can I help you explore Laravel packages today?