Laravel helpers: How to build and use custom global functions

Last week, I spent a few hours refactoring a legacy controller that was cluttered with repetitive date formatting logic. Every time I needed to display a specific user-friendly timestamp, I was rewriting the same Carbon logic, making the code harder to read and even harder to maintain. Adding custom Laravel helpers turned that mess into a single, readable function call that I could use anywhere in the app.

If you’re tired of repeating yourself, this approach is a game changer for your productivity.

Why use custom global functions?

In Laravel development, we often find ourselves reaching for the service container. While using the Laravel Service Container: A Beginner’s Guide to Dependency Injection is essential for complex logic, sometimes you just need a simple, globally accessible utility.

I initially tried to create a base controller with a protected method to handle these formatting tasks, but that quickly became a nightmare because I couldn't access it easily within my Blade templates. Switching to PHP global functions solved this perfectly. It gave me a clean, expressive way to handle repetitive tasks without needing to inject services into every single view or component.

Step 1: Create your helper file

Don't just dump your functions into app/helpers.php without a plan. I usually create a dedicated directory to keep things organized.

Create a file at app/Support/helpers.php. This is where your logic will live. Let's start with a simple example:

PHP
if (! function_exists('format_user_date')) {
    function format_user_date($date) {
        return \Carbon\Carbon::parse($date)->format('M d, Y');
    }
}

The function_exists check is crucial. Laravel loads these files early in the request lifecycle; without this check, you’ll trigger a fatal error if you ever try to redefine a function.

Step 2: Registering with Composer

Laravel needs to know that this file exists. The cleanest way to handle custom helper functions is via composer.json. Open your project's root file and add the files key to the autoload section:

JSON
"autoload": {
    "psr-4": {
        "App\\": "app/",
        "Database\\Factories\\": "database/factories/",
        "Database\\Seeders\\": "database/seeders/"
    },
    "files": [
        "app/Support/helpers.php"
    ]
},

After updating the JSON file, run composer dump-autoload in your terminal. This command forces Composer to include your helper file in every request, making your functions available globally.

Integrating helpers with other patterns

While helpers are great, they aren't a replacement for everything. If your logic involves complex state or database dependencies, you should look into Designing a clean service layer in Laravel without over-abstraction to keep your architecture sound.

I often see juniors try to put entire business workflows into a helper file. Don't do that. Keep your helpers focused on transformation, formatting, or simple shorthand. If you find yourself needing to inject a repository into your helper, you've gone too far. That’s a sign you should be using a Service Provider or a Facade instead, as discussed in Mastering Laravel Facades for Cleaner, Expressive Service Interfaces.

Best practices for Laravel helpers

• Keep them small: If a function exceeds 10 lines, it probably belongs in a class.
• Namespace awareness: Even though global functions live in the global namespace, try to name them uniquely to avoid collisions with third-party packages.
• Type hinting: Just because they are "global" doesn't mean you should skip type safety. Use PHP 8+ features to ensure your inputs are correct.

FAQ: Common questions

Do these helpers slow down the application? Not noticeably. Since they are autoloaded by Composer, the overhead is roughly equivalent to importing a standard class.

Should I use these instead of Blade components? For UI-heavy logic, use Blade components. For data transformation (like formatting a currency string or a date), helpers are often cleaner.

Can I test them? Yes. Since they are just standard PHP functions, you can include the helper file in your TestCase or create a simple unit test that calls them directly.

Final thoughts

I still find myself occasionally over-engineering solutions when a simple helper function would have sufficed. It’s easy to get caught up in "proper" object-oriented patterns and forget that PHP is a scripting language at heart.

Next time, I’d probably group my helpers by domain (e.g., app/Support/DateHelpers.php, app/Support/StringHelpers.php) if the project grows beyond 10-15 functions. It’s a small change, but it prevents the file from becoming a dumping ground for forgotten code. Start small, keep it readable, and don't be afraid to refactor later.