illuminated/helper-functions
A handy collection of Laravel helper functions that streamline common PHP tasks, reduce boilerplate, and keep your code cleaner. Easily install via Composer and use globally across your Laravel applications.
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.
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.
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.
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.composer require, 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," 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 — you'll get the same convenience with no supply-chain surface.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?